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ABSTRACT 


The goal of the CALS initiative is to enable integration of enterprises on a 
worldwide basis. The vision is for all or parts of a single enterprise, or for example, an 
original equipment manufacturer and its suppliers, or a consortium of public and private 
groups and academia, to be able to work from a common digital database, in real time, on 
the design, development, manufacturing, distribution and servicing of products. The direct 
benefits would come through substantial reductions in product-to-market time and costs, 
along with significant enhancements in quality and performance. 

Having described the Continuous Acquisition and Life-cycle Support (CALS) 
information management system (IMS) employed by the United States military to maintain 
and distribute technical support documents for weapons and materials, this thesis proposes 
an overall strategy for integrating the information management concepts of CALS into the 
infrastructure of the Army of the Republic of Korea (ROK). 
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I. INTRODUCTION 


A. BACKGROUND 

This thesis describes the Continuous Acquisition and Life-cycle Support (CALS) 
information management system (IMS) employed by the United States military to maintain 
and distribute technical support documents for weapons and materials. CALS also serves 
as a p rimar y tool used in the procurement process of these commodities, providing a 
mechanism for consistent and cost-effective acquisition. Additionally, this thesis proposes 
an orientation for integrating the information management concepts of CALS into the 
infrastructure of the Army of the Republic of Korea (ROK). 

In today’s rapidly evolving high-technology environment neither industry nor 
government — including the United States Department of Defense (DoD) — could 
operate efficiently with paper-based information processes. In the past, technical manuals 
containing engineering drawings, illustrations, and textual data used to support weapons 
systems and materials were developed and delivered to the United States government in 
paper form. The problems inherent to paper-based technical manuals are well illustrated 
by the following example. In 1980 the Ml tank was delivered to the U.S. military with 
approximately 40,000 pages of technical data and 8,000 engineering drawings for 
maintenance, whereas, in 1960 the M48 tank required only 10,000 pages of 
documentation. The U.S. Navy’s problem was greater: the USS Vincennes has 23.5 tons 
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of paper representing systems and structures above the main deck — more tonnage of 
paper than of all the weaponry on board. Many inaccuracies were found within these 
paper-based manuals. In 1992 about 10,000 technical manual discrepancies were 
reported, and the correction of these discrepancies was a very costly (up to $2,000 per 
page) and time consuming job. [Ref. 2: p. 21] 

In the mid 1980’s the DoD sought to capitalize on advances in computer hardware 
and in the areas of computer-aided design, computer-aided engineering, and concurrent 
engineering. The DoD structured a series of military specifications and standards 
facilitating the handling of weapons systems' technical data in open, digital formats. This 
pioneering effort grew into a joint DoD-Industry CALS initiative leading to procedures 
governing acquisitions from defense contractors through DoD acquisition managers 
conducted with technical data in digital formats. With this change there arose a need for 
information management systems that could receive, store, and manipulate technical data 
in various formats. Additionally, many of the acquisition management procedures 
required “reengineering,” applying concepts such as Business Process Reengineering 
(BPR) to reap the benefits of receiving, handling, and managing technical data in digital 
formats. [Ref. 4: p. 1] 

Meanwhile, major subcontractors began to implement Electronic Data Interchange 
(EDI) contracting programs with their smaller suppliers. The President of the United 
States made a commitment in an October 1993 Executive Order to start using EDI in new 
procurement systems currently being developed across all federal agencies. The largest of 
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the United States procurement agencies, the DoD, is notifying its existing and potential 
suppliers that all simplified acquisition procurement actions will be electronically based by 
the year 1997. In support of this action, the United States Congress raised the simplified 
acquisition procurement level from $25,000 to $100,000, contingent upon this electronic 
achievement in the FY '95 DoD Budget resolution. The CALS strategy and government 
and industry mechanisms now being defined and implemented can help make it happen. 
[Ref. 7: p. 11] 

Using CALS as a model, countries on the Pacific Rim and in Europe are realizing 
the potential benefits and comparative urgency of implementing a similar acquisition 
strategy. Several countries have been holding individual or group CALS Conferences 
during the last few years, such as CALS Pacific ‘94, CALS Japan ‘94, and CALS 
Australia ‘94. 

The concepts and utility of CALS have also sparked discussion in Korea. The 
Korean Ministry of National Defense (MND) has developed new weapons systems (e.g., 
the Army's K1 tank, the Air Force's Korean Fighter Program (KFP), and a destroyer class 
of ships and the first submarine in the Navy) using some non-integrated, industrial, 
CALS-compatible applications (e.g., EDI, SGML, CAD, CAM, etc.). Recently, however, 
the MND has recognized the relevance and significance of integrated CALS concepts for 
its new weapon systems, as well as implementing CALS support for older ones. 
Currently, the CALS Committee of the Computer and Communication Promotion 
Association of Korea (CCPAK) plays the leading role for CALS activities on the industrial 
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side. On the government side, the Ministry of Information & Co mmuni cation (MIC) and 
the Ministry of Trade, Industry & Energy (MTIE) has established long term plans for 
implementing CALS. Also MND is studying the issue to develop a basic plan for Korean 
CALS implementation. In the future, more detailed plans will be developed by the Korea 
Institute for Defense Information System (IDIS), and, the Agency for Defense 
Development (ADD) is slated to develop an Integrated Weapons Systems Data Base 
(IWSDB) as a model for the services. [Ref. 5] 

B. WHAT IS CALS? 

1. CALS Origin 

CALS began in the mid-1980’s as a defense industry project to exchange technical 
data directly with the government in electronic format rather than on paper-based 
documents. [Ref. 2: p. 17] After CALS became an official program, the CALS/CE 
(Concurrent Engineering) Industry Steering Group was established. This group tried an 
integration of various existing information technologies to achieve their initial goals, 
continuously adding new elements as their purposes changed. 

The early CALS goal of electronic interchange of technical data directly with the 
government was prompted by the knowledge that paper-based information is expensive to 
produce and difficult to maintain. Both industry and government reasoned that electronic 
data would be easier to generate, distribute, and maintain, requiring less storage space, 
and being less costly and more timely to update and maintain. 
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The "CALS" acronym has evolved over time. In 1985, CALS began as “Computer 
Aided Logistic Support,” defined as transiting from paper-based weapons systems 
acquisition and support processes to an integrated and automated environment. This 
effort produced, essentially, an electronic document management and EDI system 

By 1988 the name expanded to include "acquisition," becoming “Computer-aided 
Acquisition and Logistic Support.” The new name represented a two-phase approach to 
implementation that was adopted with the long term (year 2000) goal of a shared, 
integrated database. In August 1988, the Deputy Secretary of Defense directed that 
routine contractual actions be implemented with CALS throughout DoD. Instead of 
simp ly better management of technical data, sharing and integration of data enabled 
overall improvements in productivity and quality. The significance of these benefits was 
recognized by government and industry alike, and today the CALS strategy is being 
adopted and adapted by organizations the world over. 

In 1993, the de finiti on of the project was changed again to “Continuous 
Acquisition and Life-cycle Support.” According to the official Proceedings of the Seventh 
Annual Conference (CALS EXPO International ‘94), jointly sponsored by DoD, the 
Department of Commerce and the CALS/CE Industry Steering Group, “this most recent 
change was meant to reflect the fact that CALS is really about information and process 
improvement, and that both are continuous and recognizes CALS as a facilitator for world 
wide process improvement and enterprise integration.” [Ref. 2: p. 17] Much of the basic 
technology to allow the initial goals of EDI is now available, and, as stated earlier, the 
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President of the United States made a commitment in an October 1993 Executive Order to 


begin using EDI as part of new procurement systems now being developed across all the 
Federal agencies. 

The emphasis of the CALS program continues to evolve as goals are achieved, 
technology matures, and theories of business management change. Today, a greater 
emphasis is placed on “reinventing government” and “continuous process improvement.” 
CALS has been looked at in this new light to ensure that it is coordinated with new ways 
of doing business. There is new emphasis on the underlying process instead of just 
automating what has always been done before. 

2. Definition of CALS 

Because CALS covers such a broad scope, it can be defined in various ways to suit 
the context of its use. 

a. DoD Aspect 

To meet the challenge of ensuring the capability and readiness of DoD 
forces in view of a threat that has been radically altered and is ever changing, a budget that 
is substantially declining, and global technology that is advancing rapidly, DoD must 
improve or reengineer its functional processes to decrease its weapon systems life-cycle 
costs. In the CALS Strategic Plan, DoD defines CALS as “a government and industry 
strategy intended to enable more effective generation, exchange, management, and use of 
digital information that supports the life cycle of a product through the use of national and 


6 


international standards, business process changes, and advanced technology application.” 
[Ref. 3] 


b. CALS Industrial Steering Group (ISG) Aspect 

The position of CALS ISG, while not unlike the government view in basic 
concepts, is distinguished by its greater emphasis on the organizational rather than purely 
informational aspects of CALS as a solution to many of current business problems. As a 

solution, CALS has following benefits: 

• Providing longevity of information : CALS uses international 

standards, assuring access to information created daily, ten or twenty 
years from now when software and hardware have evolved 
dramatically. 

• Meeting client and user needs : Providing timely access to information 
within an organization and between business partners, an organization 
can better meet the needs of its internal users, e.g., reducing data 
re-entry as well as the needs of external clients by providing better 
products quickly and less expensively. 

• Remaining competitive : Costs are reduced with the ability to rapidly 
access and exchange information within divisions of organizations, with 
suppliers, and with business partners. Organizations are able to reduce 
their costs, while producing more product, thus insuring their long term 
viability. 

• Eliminating inefficiency of paper-based systems : CALS is based on 
electronic file formats. Creating, exchanging and using information in 
electronic form eliminates mu ch of the paper that currently exists in 
offices. 

• Reducing costs while producing higher quality products : Shortens the 
production cycle of products while allowing implementation of flexible 
approaches to manufacturing and access to contracts requiring CALS 
compatibility. 
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Based on these benefits, the CALS Industry Steering Group recently 
defined CALS as “a global strategy to further enterprise integration through the 
streamlining of business processes and the application of standards and technologies for 
the development, management, exchange, and use of business and technical information." 
[Ref 2: p. 18] 

3. CALS Vision 


a. DoD Aspect 

CALS' vision is embodied in the DoD’s stated strategic goals and 
objectives as presented in the CALS Strategic Plan ‘93. In this plan, the DoD set goals 
for the advancement and application of CALS. Each goal has supporting objectives, as 
shown in the fist below: 

• To expand its relationship with industry to ensure more harmonious 
methods of operation and data exchange. Warfighting capability, the 
readiness of forces, and effective combat operations, depend in large 
part upon the DoD’s ability to capitalize on technological and 
manufacturing capabilities of the U.S. industrial base. The DoD is 
reforming its acquisition process to lower acquisition and life-cycle 
costs of products it buys and use more co mm ercial items. Supporting 
objectives are: (a) Develop a DoD and industry infostructure; (b) 
Enable “dual-use” technologies; (c) Harmonize standards and 
practices; and (d) Provide CALS expertise through education and 
training. 

• To complete the transition of its active information and business 
transactions to standard electronic formats. Achieving the full potential 
of many business process changes depends on acquiring, accessing, and 
processing data digitally. Active data need to be converted to a 
standard digital format, and the infostructure to process digital data 
must be in place. Considerable digital information must be available 
before the DoD and industry can realize benefits from the CALS 
infostructure. Supporting objectives are: (a) Modernize hardware and 
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software; (b) Acquire new digital data; (c) Convert existing data to 
digital form; and (d) Conduct business transactions in digitally. 

• To continue progress toward integration of the DoD’s digital 
information. This goal supports changes to business processes by 
improving availability and accuracy of information. CALS will create 
the environment for a seamless, transparent, and distributed 
mana gement of business and technical information significantly 
improving information availability. Authorized users can access this 
information to perform many functions throughout a system’s life cycle. 
The development of a DoD-wide information entity and data model 
with full attributed data elements is a key component of this effort and 
necessary to its success. Supporting objectives are: (a) Develop an 
integrated infostructure; (b) Align the Defense Integrated Infostructure 
(DII) with the National Information Infrastructure (Nil); and (c) 
Promote business process reengineering. 


b. Industrial Aspect 

The CALS ISG addressed a vision statement more concerning industrial 
side. The vision is for all or part of a single enterprise (e.g., an original equipment 
manufa cturer and its suppliers, or a consortium of public and private groups and 
academia), to be able to work from a common digital database, in real-time, on the design, 
development, manufa cturing, distribution and servicing of products. Direct benefits would 
be realized through substantial reductions in product-to-market time and costs, along with 
significant enhancements in quality and performance. 


C. WHY DOES THE ROK ARMY NEED CALS? 


Since the Korean War, the United States Forces in Korea (USFK) have played an 
important role in maintaining the security of the Korean peninsula. In March 1977, the 
Carter Adminis tration announced its plan to withdraw all U.S. ground troops from Korea. 
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Furthermore, the cessation of the Cold-War increased the possibility of local conflicts. 
From the early 1970's, Korea was stirred to develop a self-reliant defense posture by 
various international environments. As a result, MND decided that a self-reliant defense 
posture should become a priority for Korean national defense. 

Korean defense logistics relied upon U.S. military aid until the 1960's. In the 
1970's MND started to build a self-reliant defense logistics support system; and during the 
1980s it developed into uniquely Korean system. [Ref. 6: p. 173] Also MND mentioned 
in the Defense White Paper that ‘‘the future logistics environment will feature 
internationalization, with military procurement sources diversified and the importance of 
information highlighted.” With the goal of establishing a self-reliant logistics support 
system, MND has focused on developing a comprehensive defense logistics support 
system, improving military supply systems and actively promoting international logistics 
cooperation. 

By the definition of CALS, CALS is a global strategy for government and industry 
in the acquisition and logistics fields. To achieve efficient management of defense logistics 
resources, CALS could be a positive strategy for the Korean Military. The ROK Army 
also needs CALS for cost reduction. As mentioned earlier, reliance on paper-based 
processes has become exceedingly expensive. In the Defense White Paper, the Korean 
defense budgets’ proportion of the GNP is moving downward, from 5.2% in 1988 to 
3.46% in 1993, with forty-five percent of the Korean defense budget allocated for logistics 
support. This situation warrants the most cost effective logistic system available. 
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Consequently, implementation of CALS into the Korean Army Information Infrastructure 
is a reasonable consideration. 

D. SCOPE OF THESIS 

The objective of this thesis is to propose an implementation strategy of CALS as 
applies to the ROK Army. After the Joint Computer-aided Acquisition and Logistics 
Support (JCALS) structure is reviewed, application areas that are proposed or expected at 
the DoD level will be analyzed. This thesis utilized implementation lessons from the U.S. 
CALS, and, in that light, reviews the Korean CALS. Afterward, an implementation 
strategy will be suggested for the Korea Army. 

The thesis will be structured as follows. Chapter E, JCALS, Architecture and 
Components, describes requirements for the DoD CALS infrastructure modernization 
(JCALS). Chapter IE, CALS Standards for Interoperability and Integration, mentions 
standards for JCALS system, EDI and Contractor Integrated Technical Information 
Services (CITIS). Chapter IV, Application Focus Area, presents the applications which 
the prototyping JCALS site has tested, or plans to test. Chapter V, Recommendation for 
ROK Army, proposes a CALS implementation strategy for ROK Army. Chapter VI 
presents the final conclusion. 


11 



12 




II. JCALS : ARCHITECTURE AND COMPONENTS 


In CALS' strategic plan, the DoD defines goals and objectives that it will pursue in 
applying CALS throughout the Department of defense. It will apply CALS to all 
information - business and technical - used between and within the DoD, and its industrial 
partners. Implementation of the CALS vision includes infrastructure of the DoD, 
standards, policy, and regulatory considerations. [Ref. 3] 

As CALS implementation guides, DoD published guides MIL-HDBK-59A on 28 
September, 1990 and MIL-HDBK-59B on 10 June, 1994. These guides provide 
information and guidance for applying CALS strategy to the acquisition, management and 
use of digital data in support of defense weapons systems and equipment. Specific 
attention is given to detailed planning and contractual implementation of CALS 
requirements. Also, the Department of Navy (DoN) published the Navy/Marine Corps 
Manager's Desktop Guide for CALS Implementation on 30 September, 1994. This guide 
provides a compilation of the Navy’s direction and intent for the incorporation of CALS 
into defense system programs. 

A. WHAT IS JCALS 

JCALS is the DoD CALS infrastructure program employed to embody CALS 
concepts. While CALS itself is a global strategy on the part of both industry and the 
DoD, JCALS was developed from Army CALS (ACALS). In January 1991, the U.S. 
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Army was directed to include the joint requirements and provide design, development, 
acquisition, and implementation options for a joint program 

The Program Manager JCALS office defines that JCALS is a multi-site, 
interactive, distributed data information and management system PM JCALS is a Joint 
Office tasked with creating a digital environment which actively supports the 
implementation of the acquisition and logistics requirements of the services and Defense 
Logistics Agency (DLA). [Ref. 13] 

The DoD CALS infrastructure program, presently known as JCALS, provides an 
information management system to support uniform logistics, acquisition, engineering, 
manufacturing, configuration management, materiel management, and other life-cycle 
functional processes. 

To test JCALS in each of the services and ensure customer involvement and 
satisfaction early in the design and development stages of the system, six prototyping sites 
have been identified: 

• USAF Oklahoma City Air Logistics Center (OC-ALC), Tinker Air Force 
Base, Oklahoma. 

• USAF Warner Robins Air Logistics Center (WR-ALC), Robins Air Force 
Base, Georgia. 

• USA U.S. Army Missile Command (MICOM), Redstone Arsenal, 

Huntsville, Alabama. 

• USA U.S. Army Printing and Publications Command, Alexandria, 

Virginia. 

• USMC Marine Corps Logistics Base (MCLB), Albany, Georgia. 
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• USN Port Hueneme Division (PHD), Naval Surface Warfare Center, Port 
Hueneme, California. [Ref. 10: pp. 2-1] 

The prototyping sites are the real part of the CALS implementation within the 
DoD. A prototype system is a model, an experiment, and at best a preliminary version of a 
real system. Prototypes are used as the final design illustration of a system to both users 
and designers and, as such, are real, manipulatable, and can be adjusted. [Ref. 9] The 
requirements applied to prototyping sites follow the CALS standards and implementation 
guides such as MIL-HDBK-59A & B and the Navy/Marine Corps Manager's Desktop 
Guide for CALS Implementation. 

B. GENERAL JCALS SYSTEM DESCRIPTION 

1. Deployment 

Planned to begin approximately in the last quarter of 1995, the deployment of 
JCALS systems will be accomplished at approximately 250 military and DLA installations 
over several years. JCALS, together with Joint Engineering Data Management and 
Information Control System (JEDMICS), will be a major manifestation of the 
implementation of the DoD's CALS strategy. [Ref. 16] 

JCALS sites, each of which is supported by its own Fiber-Optic Distributed Data 
Interface (FDDI) backbone and departmental LANs, will be interconnected by a WAN 
that relies on DISN assets and capabilities. The connectivity offered by the WAN as well 
as the configuration of each JCALS site is depicted in Figure 2-1. 
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Figure 2-1. JCALS Architecture. 

2. Infrastructure 

The JCALS system is an open architecture design. This design style provides for 
the fixture, and is also an environment that can easily be modified to keep pace with 
changing computer technology and that can easily be tailored to local requirements. For 
example, peripheral equipment that are required at particular JCALS sites can be 
acco mmo dated by simply adding them to the initially deployed system and, since a very 
high percentage - approximately 95% - of the system software is COTS 
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(commercial-off-the-shelf), applications can be changed or added with relative ease. Even 
though each site can utilize differing quantities and types of peripheral equipment, the 
basic configuration at each site will be functionally identical. 

The infra structure of JCALS system should include several means of 
communicating over geographic distances that provide the JCALS users powerful tools 
for accomplishing a large percentage of their daily tasks. These means include: the JCALS 
Workflow Manager, JCALS Workfolder, JCALS In Box/Out Box utilities, and JCALS 
Mail system. The infrastructure designed and deployed as JCALS system provides the 
basis for the DoD to begin implementing the CALS initiative that began in the mid-1980's. 
The initial functionality included in the initial deployment of the system is the Technical 
Manual system [Ref. 16] 

3. JCALS Infrastructure Capability Features 

Several major features in the JCALS system provide basic infrastructure 
capabilities that permit f ulfillme nt of the CALS initiative. The following paragraphs briefly 
describe these features. [Ref. 16] 

a. Reference Library/Reference Library Search 

A signifi cant portion of the JCALS infrastructure is the Reference Library - 
a major element of the JCALS distributed data base capability - and the means to search 
the library for specific documents. The library provides users with an electronic repository 
for publications, documents, engineering drawings, graphics, etc., that are available in the 
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JCALS system. This library provides JCALS users with worldwide access to any 
publication, document, drawing, etc., that they may need. Depending upon an individual's 
permissions or authority established in their assigned user ID code, they will be able to 
view and/or revise the source documents contained in the Reference Library. All items in 
the Reference Library are cataloged based on a number of categories such as data type, 
subtype, responsible service, proponent, etc. The Reference Library Search capability 
provides users with a choose/filter window to define criteria that the system will use to 
locate the exact documents the user desires. [Ref. 16] 

b. Workflow Manager 

A second major system infrastructure tool provides the means to create and 
define a sequence of tasks associated with a job and also create a workfolder necessary for 
that job. Also provided as part of this capability is the capability of monitoring the status 
of a job as it is being produced and generate a report that shows the status of a job and all 
in-process tasks. A completed and saved workflow creates all database links that are 
necessary to associate personnel, data, documents, and time (schedule) to a given job and 
all of the tasks associated with that job. [Ref. 16] 

c. Workfolder 

Another part of the JCALS system that is also a major part of the basic 
system infrastructure tool set is the Workfolder process. This capability, when used in 
conjunction with the Workflow Manager tool, provides easy access to all data and tools a 
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user needs to perform assigned tasks. When a task is assigned, a workfolder is 
automatically delivered to the first task manager (user) through the user's In-Box icon on 
the Desktop. Once a user opens a workfolder for the first time, it will automatically be 
placed in the user's Service. The user will retain access to a given workfolder until the job 
is completed, even though that user might have completed the assigned task. The 
workfolder does not contain actual data - rather it contains pointers to data that are stored 
in the JCALS distributed database. Since all of the users working on a job can view and 
access data simultaneously, the workfolder promotes sharing of information that is 
necessary for concurrent task efforts. [Ref. 16] 

C. JCALS SYSTEM COMPONENTS 

A key element of the JCALS System is the distributed information management 
system, which implements the Integrated Weapon System Data Base (IWSDB). This data 
base contains data that is physically resident on JCALS hardware and data that is virtually 
resident in data bases on interconnected existing systems. The information in the data base 
is available transparently to all users at all sites via the Global Data Management System 
(GDMS). The JCALS System hardware and software are divided into three major 
components in the client-server architecture. [Ref. 12] 

1. Workstation Management 

The Workstation Management component supports all processing and information 
services to the functional users. It provides all the tools and utilities users require to 
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retrieve, create, edit, and share technical data, as well as manage and coordinate all work 
activities involved with the technical processes being automated and standardized. A 
Workstation Server (WSS) processor, and its associated software and peripheral 
equipment, functions as server to a group of client workstations connected to it on a 
work-group LAN. It functions as a client of the Data Management component when 
access to the IWSDB is required. [Ref. 12] 

2. Network Management 

The Network Management component consists of all communications hardware 
and software required to provide secure data communications and connectivity for the 
JCALS system. It includes local and wide area communications networks to provide 
common connectivity among JCALS system elements. The Network Management 
component functions as a server to other components at the same site, and is both a server 
to - and a client of - the Network Management component at remote sites. For 
prototyping, the Network Management component is configured on the Data Management 
Processor. [Ref. 12] 

3. Data Management 

The Data Management component controls and coordinates the services required 
to access and manage the Integrated Weapons System Distributed Data Base (IWSDB). In 
particular, it provides the Global Dictionary/Directory Data Base (GD/DDB) services 
required to identify and locate information in the distributed GDMS which provides 
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integrated views of data across multiple JCALS sites and external systems. This 
component is a server to both local and remote users who need access to data stored on 
the server. It is also a client of its equivalent component at remote sites where data 
needed by local users is stored. [Ref. 12] 

D. HOST ENVIRONMENT 

If data users do not have access to the appropriate hardware, software, and 
telecommunications equipment, working in a digital data environment can become an 
obstacle course. Computer hardware must have appropriate processing speed and display 
capability to run the application software adequately. Application software must perform 
specific tasks on the data that are required by the user. Rather than re-create data, the 
appropriate computer networking system should allow users to share data and resources, 
and telecommunications equipment should allow users to transfer data easily. 
[Ref. 11: pp. 4-6] 

1. Hardware Requirements 

Computer hardware consists of the computer processor, memory, monitor, storage 
devices, and input devices. Most engineering and business single user computers use 
either an 80486-based processor, a 68040-based processor, or a Reduced Instruction Set 
Computing (RISC) based processor such as the RS-6000. 

The 80486 and 68040 Personal Computers (PCs) are the most widely used 
computers and are ideal for data-intensive applications that require low- to 
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medium-graphic displays. RISC workstations are widely used in engineering and technical 
publishing applications that require either a powerful processor for extensive calculations 
or a high-resolution graphics display for document editing. A "diskless" RISC 
workstation may provide a low-cost solution to some engineering computing needs. These 
workstations typically have a small hard disk for the operating system while the 
application software and user files are loaded from a network server. A third option is a 
graphic display workstation that supports the X-Window Motif standard. However, a PC 
with X-Windows emulation software may provide the same features at lower cost. The 
standard options for each type of computer is presented in Table 2-1. 


Table 2-1. Standard Options for PC Types [ Ref. 11: pp. 4-71 


'■4 

WINDOWS 

WORKSTATION TYPE 1 

RISC 

WORKSTATION TYPE 2 

Processor 

486 DX - 33 / 68040- 

RISC Workstation 

memory 

16 Mb 

32 Mb 

Media 

i. t : ... l 

i l l; 7. . 7 i 

Hard Drive 

350 Mb 

500 Mb 

Floppy Drive 

3.5 & 5.25 

3.5 

Tape Drive 

Optional 

Yes 

CD Drive 

Yes 

Yes 

WORM 

Optional 

Optional 

Monitor 

17" - 19" Flat SVGA 

19" - 21" High Res 

Typical Cost 

$2,500 to $5,000 

$5,000 to $50,000 
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2. Software Requirements 


The JCALS software architecture is based on the use of industry standards to 
provide an open architecture. From a user's perspective, the most important aspect of the 
software architecture is that it provides an intuitive, easy-to use interface to the functions 
performed by the computer system. 

The cornerstone of the JCALS software architecture is the graphical desktop. The 
X-desktop is the selected product as the graphical user front end to the system X-desktop 
is a customizable graphical user environment that enables users to configure their working 
environment. By providing a familiar graphical workspace, X-desktop facilitates the 
execution of applications software and the management of information in a sophisticated 
open systems environment. 

Aster’x®, a Motif-based office automation package, provides word processing, 
electronic spreadsheet, and graphics capabilities. This package, together with the calendar, 
calculator, and electronic mail packages bundled with ULTRIX® MLS+ and X-Windows, 
satisfies the office automation functional requirements. Workflow management 
functionality is provided as developed software. These products are augmented by a 
project management capability provided by the Ultra Planner® package from Productivity 
Solutions. 

In the technical publications area, JCALS has a CALS-compliant publishing 
solution. JCALS also has a Standard Generalized Markup Language (SGML) capability 
available through the use of an SGML editor by Arbortext. Technical illustrations will be 
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produced by Intercap Quickedit® and Intercap Illustrator 2®, which is the selected tool for 
converting computer-aided design (CAD) drawings into exploded-view, isometric 
technical illustrations. The actual publishing will be performed using Arbortext's 
Publisher® and Datalogics CALS Applications software. [Ref. 12] 

E. NETWORKS 

Deployment of the JCALS production system is envisioned for approximately 250 
military and DLA installations. [Ref. 15] They will be interconnected through a DoD 
worldwide digital telecommunications system managed by the Defense Information 
Systems Agency (DISA). A user at any site will he able to access data available at any of 
the other sites. [Ref. 13] 

Thusly, all benefits to be derived from JCALS are dependent on communication, 
whether it be across the office, across the base, or across the country. Co mmuni cations in 
the prototype environment are restricted to within individual sites and between prototype 
sites. Prototyping efforts have shown the efficacy of the JCALS co mmuni cation system in 
this limited setting. The ability to communicate and share data between these sites and 
major industrial partners, as well as the ability to share data and perform local business 
processes in an electronic environment, is the backbone of JCALS. The system will reside 
on each site's local area network (LAN) and communicate over a wide area network 
(WAN) with the other sites, the System operational Support Center (SOSC), and 
industrial partners. [Ref. 15] 
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In MEL-HDBK-59A, the DoD notes that the telecommunications plan of CALS 
details an approach to the development of capabilities and telecommunications services 
required to support CALS activities, consistent with the phased DoD migration to Open 
Syst ems Interconnection (OSI) standards; and that the telecommunications model for 
CALS describes the services site processes required for a successful implementation. 
These services are described by modeling site configurations and interactions. [Ref. 17] 

Each prototype site has developed their telecommunication systems to fit these 
directions. This section will refer to the PHD NSWC's examples for networks 
architecture. 

1. Local Area Network 

The JCALS prototype communicates at PHD NSWC via a LAN dedicated to 
JCALS traffic. The program utilizes four strands of Fiber-Optic Distributed Data Interface 
(FDDI) fiber-optic cables. The FDDI LAN connects five buildings in the PHD NSWC. 
Deployment the JCALS system will reside on the station backbone LAN and be available 
at approximately 142 "seats" at PHD NWSC. [Ref. 15] 

2. Wide Area Network 

JCALS prototype system communicates with remote sites via a Defense 
Information Systems Agency (DISA) Wide Area Network (WAN) (DISN). This WAN 
links PHD NSWC with the SOSC and the other JCALS prototype sites. JCALS at PHD 
NSWC is communicating with Defense Printing Service (DPS) at the Naval Construction 
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Battalion Center (CBC) Port Hueneme via a 56 Kbps circuit. The DISN will continue to 
be the WAN utilized by JCALS after deployment. [Ref. 15] 

F. GLOBAL DATA MANAGEMENT SYSTEM 

JCALS will be facilitated through the use of its multi-weapons systems IWSDB, 
Global Data Dictionary and Directory (GDD/D) services, extensive networked 
telecommunications, and its strict adherence to CALS and Corporate Information 
management (CIM) Technical Reference Model (TRM) standards. Data residing in the 
JCALS system, or in any system to which JCALS will interface (including JEDMICS), will 
be transparently available to any user with a need-to-know and proper access privileges. 
The system will provide uniform applications and services to implement joint functional 
processes through the use of the JCALS Workbench. This workbench will provide a 
uniform human-user interface (HUI) and will give transparent access to all data, 
applications, and software tools available throughout the architecture. The system, 
through the workbench, will provide a flexible work-flow management capability which 
will he tailored to suit the organizational structure of the service, command, or workplace 
while ensuring that future changes can be accommodated easily. [Ref. 8: p. 34] 

1. Integrated Weapon Systems Database (IWSDB) 

The JCALS IWSDB will provide a multi-weapons systems repository that services 
multiple acquisition and logistic functions. IWSDB will read, write, modify, delete, and 
grant application-usage permission on a need-to-know basis. Enforcement will be by a 
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multi-level secure (MLS) trusted computing base (TCB) rated initially at a B1 level of 
trust and progressing to a B3 level. JCALS will provide transparent access to technical 
information regardless of where it resides within the IWSDBs' distributed databases. All 
technical information will be strictly configuration managed. Configuration impacts due to 
changes will be identified by the JCALS object-oriented data management service. 
[Ref. 8: p. 35] 

2. Global Data Management System (GDMS) 

The JCALS GDMS will provide the services required to access and manage the 
distributed data of the IWSDB. The GDMS will respond to requests from applications or 
requests stored internally to JCALS to access, store, and manage data. One example of 
responding to requests stored internally is the production of summary data from an 
existing system to be stored on-line for access by system users. 

The GDMS will store data in the IWSDB in a physically distributed manner. Data 
may be stored where the data was created, where the data will be used most frequently, or 
in an existing system which already contains this type of data. This will involve managing 
physically distributed data that may not reside in the same location as the owner/proponent 
of the data. 

The GDMS will ensure the correctness of the user and application views and 
maintain the integrity of data accessed and modified. The GDD/D database will serve as a 
repository of data management policy and data integrity requirements for data stored in 
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the IWSDB. Existing systems will retain control and integrity responsibilities for their own 
data. The GDMS will ensure that access of existing systems data does not violate the 
official ownership or integrity rules of that system. The execution of an existing system's 
programs will be directly under the control of the existing system. [Ref. 8: p. 35] 
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ffl. CALS STANDARDS FOR INTEROPERABILITY AND 

INTEGRATION 


A. IMPLEMENTATIONS OF THE CALS MANDATE 

In August, 1988, the Deputy Secretary of Defense cited the first mandate of CALS 
usage for the acquisition of new weapons systems and major equipment in a memorandum 
to secretaries of the military department and the Defense Logistics Agency. This 
memorandum cited that the CALS standards would enable either digital data delivery or 
government access to contractor-maintained technical data bases and that, effective 
immediately, plans for new weapons systems and related major equipment items should 
include use of the CALS standards. 

The CALS standards were specified for two types of systems: 

• For systems now in full-scale development or production, program managers 
shall review specific opportunities for cost savings or quality improvements 
that could result from chan gin g weapons systems' paper deliverables to digital 
media for delivery, or access to the data using the CALS standards. 

• For systems entering development after September 1988, acquisition plans, 
solicitations, and related documents should require specific schedule and cost 
proposals for: (1) integration of contractor technical information systems and 
processes; (2) authorized government access to contractor data bases; (3) 
delivery of technical information in digital form. 

This memorandum was later codified in the Defense Federal Acquisition 
Supplement (DFARS). DFARS tasks acquisition managers and program offices for 
planned acquisitions to: 

• Implement CALS standards in new defense system acquisitions with CALS 
requirements being incorporated in the Request For Proposal (RFP) and 
eventually the contracts; 

• Describe the extent of how the CALS standards have been implemented in 
their acquisition planning; 
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• Ensure that their offices have the sufficient computer technology infrastructure 
in place and are capable of receiving and managing digital data. 

For weapons systems already in the DoD inventory, DFARS requires mangers to 
exploit the CALS standards by converting existing paper-based technical data to digital 
data. [Ref. 4] 

On June 29, 1994, Secretary of Defense William J. Perry issued a memorandum to 
the Secretaries of the Military Departments and the Directors of the Defense Agencies 
directing that "performance specifications shall be used when purchasing new syst ems , 
major modifications, upgrades to current systems, and nondevelopmental and commercial 
items, for programs in any acquisition category. If it is not practicable to use a 
performance specification, a non-government standard shall be used." Secretary Perry 
allowed the use of military specifications and standards in cases where performance 
specifications or non-government standards are not cost effective. The memorandum 
went on to state that military specifications and standards listed in the DFARS, such as the 
CALS initiative's military specifications and standards, are no longer mandatory and 
should be viewed only as guidance by program mangers. [Ref. 4: p. 16] 

How will the CALS effort be sustained under these conditions? As an example of 
how the Services balance the apparently conflicting guidance received from the Secretary 
of Defense in 1988 and 1994 concerning CALS implementation, the Department of the 

Navy (DoN) has directed its personnel on 30 September 1994 that: 

The Acquisition Plan (API should also include the following 
statement, applicable for the competitive System Dem/Val, Engineering 
and Manufacturing Development (EMD), Production and Deployment 
(P&D), and Operation and Support (O&S) efforts: 
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The [XYZ] project intends to implement CALS and Electronic 
Data Interchange (EDI) initiatives to reduce life cycle costs, improve 
product quality, reduce program risk and reduce the schedule of the design, 
development and production. The technical information required in support 
of the project will be made accessible through on -line contractor 
integrated technical information (electronic) services; physical delivery of 
data required for sustaining support activities will be in accordance with 
approved CALS format standards and specifications. For contract data 
requirements not evaluated as cost-effectively delivered to the CALS 
standards/specifications, delivery will be in mutually agreeable digital 
formats. The digital formats for all data users and user systems will be 
determined cooperatively between the government and contractor using the 
Government Concept of Operations (GCO), developed by the government 
program office, as the basis for selection. 

The draft and final RFPs will incorporate requirements for the offer 
or to address implementation of concurrent engineering and digital 
delivery/electronic access of program technical information. Significant 
weighting will be applied to the CALS and EDI elements in source 
selection evaluation (not less than 10 percent of the total evaluation/rating). 
Offerors will be evaluated on their ability to provide integrated, shared 
databases environments for engineering analysis, design, manufacturing and 
logistic processes; and their use of CAD/CAM/CAE methods, product 
models/databases and simulation tools to improve product design, testing, 
manufa cturing and support system development. The program will 
integrate specific program solutions with those developed by DoD/DoN 
infrastructure modernization initiatives and will implement, where value 
-effective, joint service CALS and EDI systems for the creation, 
mana gement and use of digital technical information. 
[Ref. 11: pp. 3-3, 3-4] 


B. IMPLEMENTATION GUIDELINE: MIL-HDBK-59B 

The original purpose of MIL-HDBK-59 was to provide general information and 
detailed application guidance for contractually implementing CALS requirements in 
weapons systems and related equipment procurements, to those responsible for the 
acquisition and use of the weapons systems technical data. [Ref. 18: p. 62] 
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MIL-HDBK-59 (as a CALS Implementation Guide and the superseding 
MIL-HDBK-59A) was developed by the Department of Defense with the assistance of the 
military departments. Federal agencies, and industry, and is approved for use by all 
Departments and Agencies of the Department of Defense. It provides information and 
guidance for applying the CALS strategy to the acquisition, management and use of digital 
data in support of defense weapons systems and equipment, hereafter referred to as 
'defense systems'. [Ref. 8] 

Thi s handbook provides information and guidance for applying the CALS strategy 
to the acquisition, management, and use of digital data in accordance with (LAW) DoD 
Instruction (DoDI) 5000.2. The primary focus of this handbook is the acquisition of 
digital data products and information services in support of defense systems. It addresses 
1) CALS strategy; 2) CALS policy; 3) acquisition process guidance; 4) special 
considerations for existing defense systems; and 5) DoD infrastructure modemization- 
Joint CALS (JCALS). [Ref. 8] 

MIL-HDBK-59 details a structured approach to implementing CALS 
requirements, data interchange standards, and data format specifications. Sections 2 and 3 
provide guidance to acquisition managers on the CALS strategy and CALS policy. 
Section 4 provides an overview for applying the CALS strategy to the acquisition process, 
including development of Request for Proposal (RFP) and Statement of Work (SOW) 
language, detailed planning guidance for development of the CALS Government Concept 
of Operations (GCO), and the Contractor's Approach to CALS (CAC). Special 
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considerations for applying CALS to existing defense systems can be found in section 5. 
Infrastructure consideration issues are addressed where applicable throughout, while 
section 6 provides an overview of infrastructure modernization through JCALS. [Ref. 8] 

C. STANDARDS FOR DOCUMENT SPECIFICATION 

1. Automated Interchange of Technical Information: MIL-STD-1840B 
a. Purpose 

MIL-STD-1840A, Automated Interchange of Technical Information, was 
originally published by the U.S. Air Force on 11 September 1986. Its purpose was to 
standardize the digital interface between organizations necessary for the logistic support of 
weapons systems throughout their life cycle. 

MIL- STD-1840B supersedes and enhances MIL-STD-1840A, and serves 
as a central standard for the CALS environment. MIL-STD-1840B standardizes formats 
for the exchange of digital information between organizations and/or systems to facilitate 
the development and logistic support of defense systems throughout their entire life cycle. 

MDL-STD-1840B further refines the format of data to be exchanged in the 
CALS environment, the mechanisms, and parameters of those mechanisms required for the 
exchange to take place. Additionally, MIL-STD-1840B addresses the content of 
electronic product data, new packaging of data for electronic trade business transactions, 
and electronic product data technology. 
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The M3L-STD-1840B standard formally defines, by reference, the 
configuration and structure of data files used for the transfer and archival of technical data 
in digital form. It clearly defines the record formats, standardized header records, contents 
of the files used for exchange of data, labeling requirements during shipment, protection, 
packaging, and the marking of media. Some of the provisions for "protection" of media 
require that electromagnetically inscribed information transfer media such as encoded 
magnetic tapes and disks be protected against dirt, moisture, and electrostatic discharge 
damage during shipment. [Ref. 11] 

b. Typical Applications 

The MIL-STD-1840B standard is designed to be usable for all 
CALS-related applications where information can be prepared and received as ASCII 
(American Standard Code for Information Interchange) text files, product definition data 
files, raster image files, graphics files, or contract defined data files. This standard is not 
designed to be usable for specific applications, but is not restricted in any way in its 
application. 

MIL-STD-1840B is intended for application to technical information which 
includes product data, product acquisition and implementation data, and product support 
data. Product data includes engineering drawings and specifications, as well as new and 
evolving digital data protocols which provide platform-independent data directly usable by 
a variety of unrelated computer applications. Product acquisition and implementation data 
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includes parameters and data necessary to manufacture and/or acquire an entire defense 
system Product support information includes training and maintenance manuals, 
including associated illustrations, necessary to the maintenance of a defense system in a 
required state of readiness. The scope of this data covers the entire life cycle of a weapons 
system. 

MIL-STD- 1840B further provides general requirements for Technical 
Publication, Product Data, and Electrical/Electronic Application Data File document 
types. The Technical Publications document type includes files that contain MIL-M-28001 
SGML (Standard Generalized Markup Language), Document Type Declaration with no 
text, FOSI (Formatting Output Specification Instance), SGML text entity, MIL-D-28000 
IGES (Initial Graphics Exchange Specification), MIL-R-28002 Raster, MIL-D-28003 
CGM (Computer Graphics Metafile), PDL (Page Description Language), gray scale or 
color illustration, or special word data. The Product Data document type includes files 
that represent engineering drawings in IGES or raster formats as well as numerical control 
manufacturing and 3-dimensional piping data files. The Electrical/Electronic Application 
Data Files document type includes files that contain information in the following formats: 
Electronic Design Interchange Format (EDIF), the Very High Speed Integrated Circuit 
(VHSIC) Hardware Description Language (VHDL), IGES Electrical/Electronic 
application data files, and Institute for Interconnecting and Packaging Electronic Circuits 
(IPC). 
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In any typical application, the hardware and software must prepare files for 
transfer on the sending system by adding header information and writing files to the 
selected media type. Hardware and software on the receiving system must process 
received files by reading the files from the selected media type and stripping off the added 
header information. Media to be sent must also be labeled, protected, packaged, and 
marked appropriately prior to shipment in accordance with this standard. [Ref. 11] 

c. Structure 

MIL-STD-1840B is composed of the following six sections: 

• Section 1: SCOPE. Defines the scope of M3L-STD-1840B with 
respect to standardizing the exchange of digital information between 
organizations or systems. 

• Section 2: REFERENCED DOCUMENTS. Identifies all of the 
documents upon which MIL-STD-1840B is based (See Section 2.9 of 
this overview). 

• Section 3: DEFINITIONS. Defines the abbreviations and terms used 
in MIL-STD-1840B. 

• Section 4: GENERAL REQUIREMENTS. Specifies the general 
requirements of mandatory declaration files as well as the specific 
standards, specifications, and data formats required for data files 
covered by this standard (See section 2.2 of this overview). 

• Section 5: DETAILED REQUIREMENTS. Specifies the structure, 
contents, media options, and packaging requirements for digital 
information constituting a transfer package. This section lists file 
naming conventions for both declaration and data files along with the 
header records these files require. The information required in these 
records include identifiers of the parent file, text files, and data files, as 
well as destination and source system document identifiers. Packaging 
requirements specified by MIL-STD-1840B include detailed 
instructions for labeling, protecting, marking, and packaging the 
transfer media for shipment. 
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• Section 6: NOTES. Provides information which is helpful, but not 
mandatory. [Ref. 11] 

d. Advantages of Current Standard 

MIL-STD-1840B, a standard for the interchange of digital technical data, 
is a core standard for the CALS environment. In addition to the advantage of being 
required for the delivery of CALS data, this standard has the advantage of having an 
essential function that facilitates the sharing of technical data within and among 
autonomous organizations. 

This standard clearly defines the mechanisms for exchanging digital data 
with protocols defined in other CALS specifications (MJL-D-28000, MEL-M-28001, 
MJL-R-28002, and MIL-D-28003). The reference to and use of other standards and 
specifications allows this standard to evolve synchronously, as other standards and 
specifications evolve, taking advantage of opportunities presented by advances in current 
technologies, or to effectively utilize new technologies. 

MIL-STD-1840B contains specific detailed instructions for using 9-track 
magnetic tapes as a medium for exchange of digital data. It contains flexible provisions 
which rely on agreements between sender and receiver for using other media such as 
diskettes, WORM (Write Once Read Many-times) optical disks, and CD-ROM (Compact 
Disk Read Only Memory) for the exchange of technical data. This reliance on agreements 
provides MIL-STD-1840B with the advantage of accommodating changing user needs as 
well as being able to adapt to new requirements and guidelines. 
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An additional advantage of MEL-STD-1840B is that it clearly defines the 
formats, standardized header records, and contents of files used for the exchange of data 
as well as requirements for the labeling, protection, packaging, and the marking of media 
during shipment. The standard also addresses electronic product data, new packaging of 
data for electronic trade business transactions, and electronic product data technology. 
[Ref. 11] 

e. Vendor Support 

MEL-STD-1840B has been approved for use by all agencies of the 
Department of Defense. It is required for the delivery of all CALS data. This military 
standard specifies other standards that are widely supported and accepted by national and 
international normalization organizations alike, providing a strong foundation for user and 
vendor support. 

The extent of use of MIL-STD-1840B depends upon the degree of 
accepted implementation of the standards of interchange which it specifies. Additional 
information can be obtained about users and vendors who are implementing 
MIL-STD-1840B as a part of their implementation of these CALS standards and 
specifications by reviewing the same section of the summaries for MIL-M-28001 
(SGML), MIL-D-28000 (IGES), MIL-R-28002 (Raster), or MIL-D-28003 (CGM). [Ref. 
11 ] 
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2. Digital Representation For Communication Of Product Data: IGES 
Application Subsets and IGES Application Protocols (MIL-D-28000A) 

The MIL-D-28000A military specification defines a standard for product definition 
data formats. Product definition data consists of the elements required to define a product. 
It includes geometry, topology, relationships, tolerances, attributes, and features necessary 
to define a component part or assembly of parts for the purpose of design, analysis, 
manufa cture, test, and inspection. [Ref. 8] 

a. Purpose 

MIL-D-28000A is the military specification for the digital representation of 
product definition data using the Initial Graphics Exchange Specification (IGES) as 
specified by the American Society of Mechanical Engineers (ASME) standard Y14.26M 
(Digital Representation for Communication of Product Definition Data). MIL-D-28000A 
is organized into five classes by application area to meet the general delivery needs of 
products. [Ref. 11] 

b. Application Subsets and Protocol 

MDL-D-28000A specifies five classes of the IGES standard (technical 
illustrations, engineering drawings, electrical/electronics applications, numerical control 
manufa cturing, and 3-D piping) as opposed to the entire IGES standard. MIL-D-28000A 
subdivides the IGES specification because IGES is large and complex, with different 
options that may be used to represent the same Computer Aided Design (CAD) model 
entity. 
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The first four classes of MIL-D-28000A specify the entities needed for 
specific application subsets. In this way the recipient of a M3L-D-28000A data file may 
specify the class of data needed without becoming an expert on the IGES. The only other 
entities allowed in the file are "volunteer" entities. Restrictions and specific requirements 
are placed on volunteer entities so that the CAD system that receives the file will not lose 
product information if it does not transfer the "volunteer" entities. 

The four application subsets defined within MIL-D-28000A are described 
in the following paragraphs: 

Class I: Technical Illustrations Application Subset The Class I 
application subset is for the exchange of illustrations for technical publications. The 
emphasis is on the visual appearance of the illustrations, not on the functionality of the 
entities within the class. Class I is a two dimensional subset with limited, non-geometric 
information (such as subfigures). 

Class II: Engineering Drawings Application Subset The Class II 
application subset is for the exchange of product data following MDL-T-31000 (Technical 
Data Packages, General Specification for). The emphasis is on completeness, functionality 
of the drawing model, and visual equivalency for human interpretation. The class contains 
many geometric entities, annotation entities, and attributes such as color and line fonts, 
along with organizational information such as levels and subfigures. The geometric entities 
in this class are three dimensional, though two dimensional data can be transferred by 
placing all the information on the same plane within the sending CAD system. 
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Class HI: Electrical/Electronic Applications Subset. The Class HI 
application subset is for the exchange of product data for electrical and electronic 
products. The emphasis is on completeness and functionality of the model for design, 
manufacturing, and testing. Class HI supports both the logical product representation and 
the physical product representation, which can both be in the same file. The logical 
representation includes netlists and schematics, while the physical representation includes 
assembly placement and pad layouts. Class m is difficult to use for unambiguous data 
exchange without further restrictions and interpretations applied to the subset. The 
IGES/PDES Organization (EPO) Electrical Applications Committee (EAC) is developing a 
Layered Electrical Products (LEP) AP for the representation of electrical products. The 
LEP AP is currently planned to be a replacement for MIL-D-28000 Class HI. 

Class IV: Geometry for NC Manufacturing Application Subset The 
Class IV application subset is for the exchange of product data for manufacturing by 
numerical control. The emphasis is on the completeness and functionality of the part 
model. Geometry data is either 2-D wireframe, for profiles or sheet metal, or a 3-D 
wireframe model for multi-axis machining. Precision and accuracy on the wireframe and 
surface geometry must be maintained, as well as first order continuity. Geometry and Text 
form the majority of the data for this class. [Ref. 11] 

An Application Protocol (AP) is a way to transfer defined product data 
through IGES. An AP documents the user requirements for an application in a graphical 
model called an Application Reference Model (ARM). 
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Class V: 3-D Piping Application Protocol. The Class V application 
protocol is for the exchange of product data for 3-D piping system models, but not piping 
drawings or internal details of equipment. The Class V AP conveys shape and location, 
connectivity, material characteristics, information about elements in the piping system and 
the piping system as a whole. The Class V provides information for the core requirements 
of: interference analysis, connectivity checks, basic parts lists, graphics presentation, basic 
piping isometrics, pipe bending instructions, and limited piping redesign. This Class V AP 
is not intended for general purpose CAD system, but for 3-D piping system apphcations 
only. Both the sending and receiving systems must support the specific 3-D piping system 
application and the Class V 3-D Piping Application Protocol for meaningful exchange. 
[Ref. 11] 

c. Vendor Support 

The IGES specification has gained support from CAD system vendors. 
Most CAD systems have some type of IGES translator, and even some non-CAD systems, 
such as Interleaf® (an electronic publications system), support the IGES specification. 
Support for MIL-D-28000 (i.e., the subsets) is not as widespread as support for the full 
IGES standard. The greatest stated support of the MIL-D-28000 subsets derives from 
commercial flavoring software and syntax checking software. MIL-D-28000 Class n, 
engineering drawings, is the most commonly supported class, followed by MIL-D-28000 
Class I, technical illustrations. Presently, Intergraph has a MIL-D-28000 Class V 
translator under development. [Ref. 11] 
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3. Standardized Generalized Markup Language (SGML) MIL-M-28001B 


The MIL-M-28001B specification defines a standard for preparation of textual 
technical information using the SGML. Data prepared in conformance to these 
requirements will facilitate the automated storage, retrieval, interchange, processing, and 
presentation of technical information from heterogeneous data sources. [Ref. 8] In 
essence, the CALS standard MIL-M-28001B represents the DoD implementation of the 
international standard ISO 8879 "Standard Generalized Markup Language (SGML)". 
[Ref. 11] 

a. Purpose 

The CALS SGML standard defines both a methodology and a high level 
computer language for document representation. It provides a coherent and unambiguous 
gr ammar and syntax for describing whatever objects a user chooses to identify within a 
document, regardless of the type of document or the nature of the document's text, and 
provides a formal markup procedure independent of system and output environments. 
[Ref. 11] 

b. Document Type Definition (DTD) 

Document de finiti on of structure or content in terms of "elements", their 
"attributes", "entities", and other components, is a called "Document Type Definition 
(DTD)". A DTD defines the structure or content of a specific class of document objects. 
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"SGML markup" (or an "SGML document instance") consists of 
unformatted text with inserted SGML "tags," or tokens, which correspond to the elements 
and attributes of the DTD. These tags identify elements of the text (e.g., titles, 
paragraphs, tables, and footnotes) defined in the document's DTD. The "marked up" 
document (SGML document instance) can then be "parsed" using special error editing 
software to determine if the document's tagging conforms to the DTD. [Ref. 11] 

c. Output Specification 

In order to format an SGML source file, associated structural protocol 
information must be provided. This information must define formatting characteristics 
such as page model, font and family characteristics, point size, indenting, etc. In addition, 
these formatting characteristics must be responsive to certain SGML tags. For example, a 
"paragraph" tag may trigger a change in a line leading or a "chapter title" tag may trigger 
"bolding" and "center" functions within paragraphs. The Electronic Publishing Committee 
of the CALS Industry Standards Working Group formed a MIL-M-28001 Output 
Specification Ad Hoc Group to develop a standard language for providing associated 
formatting information for SGML instances. It was decided to use SGML itself for this 
purpose and provide the associated formatting information in the form of an "Output 
Specification" (OS) DTD. [Ref. 11] 
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d Vendor Support 


The vendor co mmunit y is aware of the evolving nature of MIL-M-28001. 
Several vendors are waiting until the standard is finalized, while other vendors are 
undertaking full implementations. A large vendor community is represented on the 
Electronic Publishing Committee. For the CALS environment, vendors supporting 
MEL-M-28001 should not "hard-code" their systems to process only a single DTD or 
FOSI. Inevitably, most users will be processing a variety of technical publications which 
must conform to multiple DTDs and will require a system that can be configured to adapt 
to new and changing requirements as they arise. [Ref. 11] 

4. Raster Graphics Representation In Binary Format (MEL-R-28002) 

This militar y specification was originally conceived to fill the need for national and 
international standards for the storage and exchange of large engineering drawings as 
raster graphics files. Now known as a standardization document, its current version is 
based on ISO standards and the Consultative Committee for International Telegraph and 
Telephone (CCITT) recommendations. [Ref. 4] 

a. Purpose and Applicability 

The Mil -R-28002 specification establishes requirements for a standard 
interchange file format and raster encoding scheme for raster data. This specification 
identifies the requirements to be met when raster data represented in digital, binary format 
is delivered to the Government. 
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Raster graphics involves the digital processing, storage, exchange and 
reproduction of images. This technology supports the binary representation of a 
two-dimensional image as an array of picture elements, also known as pels. Each pel of 
the array contains information about that portion of the image. This information may 
include its lightness, darkness, gray-level and color. The quality of the image depends 
directly on the density of pels within the array, also known as resolution density or pel 
transmission density. High resolution density provides a high quality image, but at the 
expense of higher storage costs. Data compression, in which an encoding scheme is used 
to represent redundant data bits of information, can alleviate this storage problem to some 
extent. MIL-R-28002 restricts such compression to Group 4 encoding as defined in 
Consultative Committee on Telegraph and Telephone (CCITT) Recommendation T.6 in 
order to conform to developing industry standards. 

MIL-R-28002 permits two types of digital representation of raster data, 
referred to as Type I and Type II in the specification. The Type I file format is used for 
raster data contained in a single monolithic block of compressed data and is called untiled 
raster data. The Type II file format is an Open Document Architecture (ODA) document 
(as specified by ISO 8613 ODA) conforming to a special application profile for raster 
images. Type II may be tiled raster data or may consist of a single compressed block of 
data as in Type I, but with all ODA parameters and data structuring included. 

Type I raster data interchange is intended to be used in procuring data for 
systems that only utilize untiled raster data representations. Examples of such systems 
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include typical technical documentation systems, the Air Force Engineering Data 
Computer-Assisted Retrieval System (EDCARS) and the Army Digital Storage and 
Retrieval Engineering Data System (DSREDS). A set of graphics attributes specifying the 
details necessary for processing and reproducing the image must be included in a header 
record at the beginning of the raster file. These attributes include the size of the original 
image, scanning resolution, image orientation (portrait or landscape), starting position on 
the page, and spacing between pels and lines containing the pels. These attributes are used 
in reproducing the image and apply to both Type I and Type II raster data files. 

Type II raster data interchange is intended to be used in procuring data for 
systems that need the flexibility to use tiled or a mixture of tiled and untiled raster data 
representations. Tiled representations are best applied in systems handling large format 
drawings or illustrations typically associated with engineering design. The subdivision of a 
drawing into tiles allows the use of only those portions of an image required at a given 
time by the application. This can result in reduced requirements for workstation memory 
and display. Attributes required for Type I are also required for Type II data and are 
encoded in the ODA data stream as specified by the ODA Raster DAP (as explained 
below). For Type II data, additional attribute information must be included to cover the 
size of each tile, the number of tiles in the array (image), the method of tile ordering, and 
the method of tile coding. This information is stored in the header record of an image file 
during the scanning process and is essential for reproducing the image. [Ref. 11] 
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b. Advantages of Current Specification 


MIL-R-28002 reflects the intent of the OSD to use existing and emerging 
international standards as the basis for implementation. The ODA standard provides for 
storage of complex documents containing graphics and textual information and production 
of compound documents using facsimile technology. ODA was cited for Type II raster 
data specification in an effort to ensure that raster image data specification efforts align 
with evolving international raster imaging standards while promoting interop erability with 
other raster data formats used in the open document architecture standard. [Ref. 11] 

c. Vendor Support 

The Electronic Imaging/Compression Co mmit tee of the Association for 
Information and Image Management (AIIM) has developed a standard: ANSI/AIIM 
MS53 1993, the Standard Recommended Practice - File Format for Storage and 
Exchange of Images - Bi-Level Image File Format: Part 1, that specifies file formatting 
for exchange of bi-level, electronic images. MS53 is considered a subset of the ODA 
Raster DAP, but it does not allow for the tiling of raster images. This standard was 
developed to encourage the use of ODA by the United States image technology 
co mmunit y and to provide a much needed standard bi-level image file format. It is seen as 
an introductory tool for users and implementors of ODA, ASN. 1 and ODA Raster DAP 
applications requiring MIL-R-28002 Type II untiled data. MS53 is AIIM's attempt at a 
"cookbook" approach for exchanging bi-level electronic images using ODA with ASN. 1 
encoding. 
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5. Digital Representation For Communication Of Illustration Data: 

Computer Graphics Metafile (CGM) (MIL-D-28003) 

Military specification, MIL-D-28003, "Digital Representation of Illustration Data: 
Computer Graphics Metafile (CGM)", specifies an application profile of the International 
and U.S. standards for CGM and certain specific additional requirements. The Computer 
Graphics Metafile standard is a published International Standard (ISO/IEC 8632), a 
Federal Information Processing Standard (FIPS 128), and has been adopted by the 
American National Standard Institute (ANSI). CGM is being developed and maintained 
through a coordinated effort of ISO SC24 and ANSI X3H3. U.S. and international 
standards are identical. [Ref. 11] 

a. Purpose and Applicability 

The overall intent of the CGM standard is to provide the lowest level of 
drawing functionality required to capture and reproduce a picture in a way that is portable 
across non-aligned applications and devices. CGM specifies two-dimensional graphics 
data interchange in a file format that can be created independently of device requirements 
and translated into formats required by specific output devices, graphics systems, and 
computer systems. 

A metafile is a device-independent, application-independent storage format 
for the exchange of data that makes up a picture ("picture data"). Metafile definition in 
ISO/IEC 8632 includes a specification of output primitives and attributes that may be used 
to compose an illustration represented by an intentionally under-specified semantics 


49 



(meaning). This was done to accommodate a wide range of existing systems, and to make 
the standard more adaptable to the requirements of diverse applications and users. If the 
application software is directed to store a picture on a metafile, it has to write all of the 
information required for reassembly into a file. Software that performs CGM writing 
actions is called the "generator". Software that can read a metafile back into an 
application and reconstruct the intended image is called an interpreter. 

A "profile" addresses implementation conformance requirements for the 
generator and interpreter. For generators, the graphical characteristics of the picture are 
mapped onto a set of CGM elements which define the images within the accuracy and 
latitude defined by the implementation requirements in the profile. For interpreters, the 
graphical characteristics of the CGM elements are rendered into a graphical image or 
picture within the latitude defined by the implementation requirements set forth in the 
profile. Without a profile, one can only address the syntactical correctness of the data 
stream With a profile, one can address and test that the picture is correct. Profiles 
provides a way of standardizing and publicly specifying the options that a vendor supports 
and how they are to be supported. [Ref. 11] 

b. Advantages 

The CGM contains device-independent, digitally-encoded vector and raster 
graphics data. CGM files are easily transferred and displayed on a wide variety of 
hardcopy devices (dot-matrix, ink-jet, electrostatic, and laser printers, pen plotters, and 
film cameras). CGM files can also be easily previewed on an extensive range of softcopy 
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terminals. In comparison to Raster, CGM is easily modifiable, generally of much smaller 
size, and not dependent upon resolution of the output device. CGM compares to IGES 
(2-D data), CGM is faster to interpret and display, and again more compact. The selection 
of which of the CALS graphic standards (raster, IGES, or CGM) that best fits the 
application, should be the result of the thorough examination of the processes involved in 
the application. [Ref. 11] 

c. Vendor Support 

This standard associated with its Application Profile is considered a subset 
of the international and national CGM standard. Many vendors who claim CGM standard 
conformance, do not completely conform with MIL-D-28003A because of the lack of 
Application Profile details necessary for use with CALS applications. Currently six 
software vendors (Ashton-Tate, Computer Support, Lotus Development, Micrografx, 
Hewlett-Packard, and Software Publishing) offer applications that can import and export 
CGM files conforming to MIL-D-28003A. Numerous other vendors offer applications 
that can either import or export CGM files or can both import and export CGM files, but 
only in conformance with the previous version of this specification. DoD organizations 
p lanning to use a drawing application for CALS compliant illustrations should be certain 
that the application explicitly conforms with the import and export requirements of 
MEL-D-28003A. [Ref. 4] 
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D. STANDARDS FOR INTERNETWORKING 


The resources of a single network are often inadequate to meet user's needs. 
Because networks that might be of interest exhibit so many differences, it is impractical to 
consider merging them into a single network. Rather, what is needed is the ability to 
interconnect various networks so that any two stations on any of the constituent networks 
can co mmuni cate with one another. 

An interconnected set of networks may appear simply as a larger network. 
However, if each of the constituent networks retains its identity, special mechanisms 
(known as communications protocols) are needed for communicating across multiple 
networks. The entire configuration of internetworked networks is often referred to as an 
internet, and each of the constituent networks as a subnetwork. [Ref. 19: p. 471] 

According to the JCALS plan, about 250 sites and contractors should 
communicate between each other across the internet. In the MIL-HDBK-59A, DoD 
described three telecommunication options in the current environment: contractor-specific 
network architecture, OSI compatible network architectures, and Transmission Control 
Protocol/Intemet Protocol (TCP/IP)-based Defense Data Network (DDN) architectures. 
[Ref. 17: p. 177] Of these three network architectures, this section will present last two 
architectures as options because of their popularity and open networking capabilities. 
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1. Open Systems Interchange (OSI) 


a. Background 

OSI protocols have been developed by international standards 
organizations, primarily the International Organization for Standardization (ISO) and the 
Consultative Committee on International Telephone and Telegraph (CCITT). 

As the use of computer communications and computer networking 
proliferate, a one-at-a-time special-purpose approach to communications software 
development is too costly to be acceptable. The only viable, cost-effective alternative for 
computer vendors is to adopt and implement a common set of conventions. For this to 
happen, a set of international or, at least national, standards must be promulgated by 
appropriate organizations. [Ref. 19: p. 436] 

The International Organization for Standardization (ISO), the Consultative 
Committee on International Telephone and Telegraph (CCITT), and other standards 
formulation bodies have adopted a seven-level OSI Reference Model for guiding the 
development of international standards for networks of computers. It is called a "reference 
model" because it only recommends the functions to be performed in each of seven layers. 
The model does not specify detailed standards for each layer. Those are left up to 
individual standards bodies in adopting countries. [Ref. 20: p. 188] 

The term Open Systems Interconnection (OSI) qualifies for the exchange 
of information among systems that are "open" to one another for this purpose by virtue of 
their mutual use of the applicable standards. Hwever, the fact that a system is open does 
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not imply any particular systems implementation, technology, or means of interconnection, 
but refers to the mutual recognition and support of applicable standards. [Ref. 19: p. 436] 

b. Concepts 

A widely accepted structuring technique, and the one chosen by ISO, is 
"layering ." Communications functions are partitioned into a vertical set of layers. Each 
layer performs a related subset of functions required to communicate with another system. 
Layering relies on the next lower layer to perform increasingly more primitive functions 
and to conceal the details of those functions. At the same time, it provides services to the 
next higher layer. Ideally, layers should be defined so that changes in one layer do not 
require changes in preceding or succeeding layers. Thus we have decomposed one 
problem into a number of localized, more manageable subproblems. 

The task of the ISO subcommittee was to define a set of layers and the 
services to be performed by each layer. The partitioning should group functions logically, 
should have enough layers to make each layer manageably small, but should not have so 
many layers that the processing overhead imposed by the aggregation of layers is 
burdensome. 

The attractiveness of the OSI approach is that it promises to solve the 
heterogeneous computer communications problem. Two systems, no matter how 

different, should be able to communicate effectively if they have the following in common: 

• They implement the same set of communications functions. 
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• These functions are organized into the same set of layers. Peer layers 
must provide the same functions, but note that it is not necessary that 
they provide them in die same way. 

• Peer layers must share a common protocol. 

The OSI model, by defining a seven-layer architecture, provide a 
fr ame work for defining these standards. [Ref. 19: pp. 437-441] 

c. OSI in the CALS 

OSI compatibility, the telecommunications technology that industry as well 
as government is moving rapidly to implement, is cited as one of the options for CALS 
telecommunications in MIL-HDBK-59A. Federal Information Processing Standards 
Standard Number 146 (FEPS 146) adopts the Government Open Systems Interconnection 
Profile (GOSIP) Version 1 for government use. GOSEP defines a common set of data 
communications protocols which enable computer systems developed by different vendors 
to interoperate and exchange data. GOSIP version 1 includes requisite information for 
acquisition of the OSI FTAM (File Transfer and Access Management) and VT (Virtual 
Terminal) applications as well as the various lower layers of protocol to support them. 
This suite of co mmuni cations protocols include the most popular physical media including 
token ring, broadband, and Ethernet. [Ref. 17: pp. 178] 

MIL-HDBK-59A emphasis also that OSI should be the sole, mandatory, 
interoperable protocol suite for new procurements involving new Automated Information 
Systems (AISs) or major upgrades to existing AISs, including network services. 
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2. TCP/IP-based DDN 


a. TCP/IP Background 

Despite of predating of TCP/IP from OSI and far more implementation and 
practical experience, little attention has been given to TCP/IP. TCP/IP is an outgrowth of 
the development of Advanced Research Project Agency computer NETwork (ARPANET) 
and the Defense Data Network. Whereas the OSI architecture is intended to guide the 
future development of protocols, it is the experience already gained in the development 
and use of protocols within ARPANET that has led to this communications architecture. 

Both OSI and TCP/IP deal with communications among heterogeneous 
computers. Both are based on the concept of communications-specific protocol 
architectures and have many similarities. However, there are philosophical and practical 
differences between the OSI model and the TCP/IP model. [Ref. 19: p. 451] 

b. Characteristics 

The DoD has issued standards for a set of communications protocols. Its 
motivations are similar to those of the ISO and many other computer systems customers. 
DoD needs to have efficient, cost-effective communications among heterogeneous 
computers. There are three reasons why the DoD has chosen to develop its own protocols 
and architectures rather than adopt evolving international standards. These are explained 
as follows: 1) The DoD protocols were specified and have enjoyed extensive use prior to 
ISO standardization of alternative protocols. Because, at the time of creation, the DoD 
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needs were immediate, it was deemed impractical to wait for the ISO protocols to evolve 
and stabilize. 2) DoD- specific communications requirements have a major impact on the 
design of industry-accepted protocols and architectures. These concerns have not been 
uppermost in the minds of the ISO developers, and predictably are not reflected in the OSI 
model. 3) Philosophic differences exist between perceived DoD and industry requirements 
concerning the appropriate nature of communications architectures and protocols. 
[Ref. 19: p. 451] 

The first reason is self-explanatory. The second reason is the specific DoD 
requirements, many of which are also relevant in other contexts, such as survivability, and 
include availability, security, network interoperability, and the ability to handle surge 
traffic. The third reason is best explained by examining the differences between TCP/IP 
and the OSI model. There are four fundamental differences: 

1) The concept of hierarchy versus layering. The TCP/IP protocol 
recognizes that the task of communications is too complex and too diverse to be 
accomplished by a single unit. Therefore, the task is broken up into modules or entities 
that may communicate with peers in another system One entity within a system provides 
services to other entities and, in turn, utilizes the services of other entities. The OSI model 
is based on similar reasoning, but takes it one step further. The next step is recognition of 
protocols at the same level of the hierarchy that have certain features in common. This 
yields the concept of rows, or layers, and the attempt to describe in an abstract fashion 
which features are held in common by the protocols within a given row. 
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2) The importance of internetworking. A historical difference between 
the TCP/IP and OSI models is the importance that TCP/EP places on internetworking. 
Internetworking occurs when two communicating systems do not attach to the same 
network. Thus transferred data must traverse at least two networks, usually through an 
interface router known as a "gateway." Both the initiating and receiving networks may be 
quite dissimilar. The requirement for internetworking has led to the development of an 
Internet Protocol. Such a protocol was not originally given a place within the OSI model. 
The current OSI document makes brief reference to the possibility of networks in tandem, 
and an internet protocol has emerged as sublayer of the network layer (layer 3). This is not 
a clean solution, but it is not the only one possible within the seven-layer architecture. 

3) The utility of connectionless services. A connectionless service is one 
in which data are transferred from one entity to another without the prior mutual 
construction of a connection. TCP/IP places equal importance on connectionless and 
connection-oriented services, whereas the OSI model is couched solely in terms of 
connection-oriented services. It is expected, however, that further versions of the OSI 
model will incorporate connectionless services. 

4) The approach to management functions. A final difference between 
the TCP/IP and OSI models is the way in which various management-related functions are 
treated. 

The concept of management functions seem not to meld well with the OSI 
model, partly because these are mostly connectionless services, partly because there is no 
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"place" for them. TCP/IP does not preclude this approach, rather it goes further. Within 
this architecture, a unif orm approach is taken to many of these functions and they are 
provided by protocols that can best be described as "session layer" protocols. This 
description reflects the fact that these protocols make use of transport services. 
[Ref. 19: pp. 451-454] 

c. Architecture 

The TCP/IP architecture is based on a view of communication that involves 
three agents : processes, hosts, and networks. Processes are the fundamental entities that 
communicate between initiators and recipients. Processes execute on hosts, which can 
often support multiple simultaneous processes. Co mmuni cation between processes takes 
place across networks to which the hosts are attached. These three concepts yield a 
fundamental principle of TCP/IP: the transfer of information to a process can be 
accomplished by first getting it to the host in which the process resides and then getting it 
to the process within the host. With this in mind, the DPA organizes TCP/IP protocols 
into four layers: 

• The network access layer contains those protocols that provide access 
to a co mmuni cation network. Protocols at this layer exist between a 
co mmuni cations node and an attached host or its logical equivalent. 

• The internet layer consists of procedures required to allow data to 
traverse multiple networks between hosts. 

• The host-host layer contains protocol entities with the ability to deliver 
data between two processes on different host computers. 
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• The process/application layer contains protocols for resource sharing 
(e.g., computer-to-computer) and remote access (e.g., terminal-to- 
computer). [Ref. 19: pp. 455-456] 

d. DDN in CALS 

DDN is mentioned as a CALS telecommunication option in the 
MIL-HDBK-59A. Because the DDN is a DoD network, sized to support defense 
requirements within available funding, the acquisition manager must provide sponsorship 
for defense contractor nodes, and must satisfy defense Communications Agency 
requirements to justify and schedule connection to the network. The DDN is currently 
based on TCP/IP standards which are widely supported in government and industry with 
many commercial, off-the-shelf products. However, the DoD has committed to 
accompany industry in it's transition to Open System Interconnection (OSI) compatible 
products, implemented through new standards such as the Government OSI profile 
(GOSIP). [Ref. 17: pp. 178] 

E. EC/EDI 

1. Background 

The concept of EC/EDI started over 30 years ago. During the 1960s, the 
Transportation Data Coordinating Committee (TDCC) of the United States became 
concerned about the strangling effect of paperwork on the transportation industry. In 
1975, the TDCC published the first set of rules for EDI, many of which still apply. At that 
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time, computer hardware, software, and networks were not capable of supporting these 
new business procedures. In 1979, the American National Standards Institute (ANSI) 
approved TDCC's approach to EDI access and use, as embodied in the ANSI X12 
standard. Since then, the ANSI X12 committee has generated over 20 cross-industry 
transaction data format variations on the basic theme to accommodate unique situations in 
diverse business areas. [ Ref. 21: p. 3] 

2. Definitions 

Electronic Data Interchange (EDI) is the intercompany, computer-to-computer 
exchange of business documents in standard electronic data formats. Transaction data is 
transmitted from the sending company’s application to the receiving company's application 
without human intervention. Transactions (also called transaction sets) include invoices, 
shipping schedules, advance ship notices, court filings, bills of lading, and purchase orders. 
These are transformed to a standard data format and electronically transferred between 
trading partners without utilizing hard-copy or re-keying information. Standard transaction 
sets are approved by ANSI in the X12 standard. [Ref. 21: p. 3] 

Electronic Commerce (EC) includes EDI, but recognizes the need for inter¬ 
personal (h uman -to-human) communications. Of the transfer activities that aid in 
communications technologies, EC is significantly broader than EDI. [Ref. 22: p. 7] EDI is 
the primary technology for achieving EC. EC also may include electronic mail (E-mail), 
electronic bulletin boards (BBS), electronic funds transfer (EFT), and similar technologies. 
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EC is used to reduce paperwork, communicate faster, reduce errors, reduce data entry 
costs, strengthen trading partner relationships, and lead to more effective decision making. 
[Ref 2: p. 37] 

3. EC/EDI in the Government/DoD 

In 1993, the President of the Unites States signed a memorandum directing the 
Federal Agencies to actively pursue streamlining of the procurement process through the 
implementation of Electronic Commerce (EC), a forum successfully used by large and 
small businesses alike for a number of years. In the memorandum, the President noted 
that moving to an Electronic Commerce (EC) system to simplify and streamline the 
acquisition process will promote customer service and cost-effectiveness. The electronic 
exchange of acquisition information between private sector and Federal government 
agencies (i.e., the use of EC) will increase competition. It will do so by improving access 
to Federal contracting opportunities for the more than 300,000 suppliers currently doing 
business with the Federal government. Enhanced opportunities would be, through this 
mechanism, provided for small businesses and many other suppliers who find access to 
bidding opportunities difficult under the current system. To these ends, the President set 
forth the following objectives for EC: 

• Exchange of acquisition information electronically between the private sector 
and the Federal government to the maximum extent practicable. 

• Provide businesses, including small, disadvantaged, and women-owned 
businesses, with greater access to Federal acquisition opportunities. 


62 



• Ensure potential suppliers are provided simplified access to the Federal 
government's EC system. Employ nationally and internationally recognized 
data formats that serve to broaden and ease the interchange of data. 

• Use agency and industry systems and networks to enable the government and 
suppliers to exchange information and access Federal acquisition data. 
[Ref 23: pp. 45-46] 

The task of developing the architecture and overseeing implementation of EC was 
assigned to the Electronic Commerce Task Force under the President's Management 
Council (PMC). In order to complete the task of the President's memorandum, the task 
force chartered a Federal Electronic Commerce Acquisition Team (ECAT) and directed it 
to develop a comprehensive plan for implementing an EC capability. [Ref. 23: p. 46] 
ECAT recognized that the proliferation of implementation conventions is a major 
stumbling block in the use of EDI as the foundation of EC, and recommended the 
development of Federal Implementation Conventions. [Ref. 24: p. IT-198] 

4. Standards for EDI Implementation Convention 

There are two worldwide known standards for EDI: X12 and United 

Nations/Electronic Data Interchnage For Administration, Commerce, and Transport 
(UN/EDIFACT). In 1979, ANSI chartered X12, Electronic Data Interchange, to develop 
uniform standards for electronic interchange of business transactions. It was formed by 
joining together two industry standards groups that had been developing EDI standards 
since the late 1960s, and that had foundation documents to draw from immediately. 

The history of EDIFACT is relatively brief. The United Nations Working Party 4 
on Facilitation of International Trade Procedures began its work on international 
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EDIFACT standards a decade later, and did not adopt its first message until 1987. During 
the 1990's rush to a global marketplace, the European Community 92's lifted European 
trade restrictions, and the heavy use of EDI for customs clearance in the Pacific Rim 
countries and New Zealand make international EDI standards a business imperative. This 
has caused UN/EDIFACT to grow swiftly. [Ref. 25: p. 55] 

In spite of the late starting of UN/ED1FACT standards, worldwide adoption of 
these standards as the basis for international exchange of computer-processable business, 
including product data, is resulting in a rapidly multiplying set of competitive commercial 
networks, products, and services to implement UN/EDIFACT-based EDI. 

At the American National Standards Institute (ANSI), Accredited Standards 
Committee (ASC), June 1993 meeting, the ASC X12 organization formalized its intention 
to migrate its standards to alignment with UN/EDEFACT. X12 voted to adopt 
UN/EDIFACT as a single standard after the release of Version 4 of the X12 American 
National standards, which is expected in 1997. The release of Version 4 is seen as the 

logical beginning for migration of X12 to UN/EDIFACT. 

The recent ASC X12 decision to migrate to UN/EDIFACT underscores the 
emerging importance of these international standards. [Ref. 25: p. 54] 

5. EDI on the Internet 

EDI, by definition, includes the direct transmission of data between firms, 
transmission using an intermediary such as a value-added communication network (VAN) 
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or bank, and the exchange of computer tapes, disks, or other storage devices between 
locations. [Ref. 26] 

There is an easy way to access and use EDI: the Internet. The Internet is the 
inter-connection and synergism of existing, connected corporate and government 
networks u tilizin g commonly used telecommunications standards. [Ref. 22: p. 6] The 
Internet can be used to do business just like using telephone (and many times it is accessed 
through dial-up protocols). The same Internet connection an organization uses to send 
electronic mail could also be used to send EDI transactions. 

There are benefits for EDI from Internet: 

• Adoption of common standards and proven inter-operable systems. 

• Adoption and deployment of a distributed Directory Service capability, so that 
one can readily contact, electronically, any other organization in the world. 

• Explicit co mmitme nt by participating organizations to cooperatively route 
traffic, work to resolve addresses, and meet required standards. 

• Layering of applications (such as EDI) over existing, proven applications. 

• A standards process with reference implementations which all vendors have 
equal access. 

• Widely available public domain software including, but not limited to, 
applications, ptotocol/transports and multiple platform development tools. 
[Ref. 21: pp. 7-8] 

While EC/EDI will certainly improve the internal communications and business 
processes of individual enterprises with the above mentioned benefits, the real payback 
comes when EC is implemented on an inter-enterprise basis. It is the inter-enterprise 
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world in which security needs become most obvious, beginning with authentication and 
non-repudiation, and continuing into privacy through encryption. [Ref. 27: p. 24] 

As the methods for them, Ellingen mentioned some of the details in his article; For 
EDI authentication and non-repudiation: the digital signature 1 based on HyperText 
Transfer Protocol (HTTP) 2 Security; and privacy; public key encryption. 

EC/EDI are bringing major changes to the world of business domestically and 
internationally. It is fitting that the largest international network, the Internet, should be 
coming into greater use. Furthermore, secure EDI over Internet is available now. 
[Ref 27: p. 26] 

F. CmS : MIL-STD-974 

1. Introduction 

The Contractor Integrated Technical Information Service (CITIS) is a contractor 
-developed and maintained service providing electronic access and/or delivery of 
government-procured contractually required information. CITIS is generally acquired 
from prime contractors who may also use electronic networks for access and delivery of 
information from their suppliers. Thus, the prime contractor is the information integrator 
for a specific program/product acquisition. The ultimate goal of CITIS and CALS, in 

l A digital signature contains two components: 1) An undeniable statement of the identity 
of the person who signed the document; 2) A unique mathematically-computed number, 
or "fingerprint" of the document which is signed. [Ref. 27, p. 25] 

2 A protocol used in the World Wide Web (WWW) technology which will be the basis of 
may CommerceNet applications. [Ref. 27, p. 24] 
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general, is to reduce lead times and costs for weapons systems design, manufacturing, and 
support processes, and at the same time assure technical information accuracy and 
timeliness. Figure 3-1 compares current, typical business practices with the program 
operation in the CITIS environment. [Ref. 11: p. (7)-3] 



Figure 3-1. Current Operating Environment vs. CITIS Environment [Ref. 11: p. (7)-4] 


2. Purpose of CITIS Requirements 

This standard is designed to be incorporated into a contract to define the functional 
requirements for a computer-based service to provide access to information. CITIS is 
intended to be an efficient, contractually implementable means for providing the 
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government with on-line access to contractor generated data and Government Furnished 
Information (GFI) and the electronic transfer of such data. Ultimately, CITIS will replace 
most, if not all, contractor delivery of hard copy information currently required by the 
government throughout a programs life-cycle. The requirements are specified in terms of 
information services and functions which must be selected to meet the needs of each DoD 
acquisition program. [Ref 28: p. 12] 

The U.S. government encourages industry to utilize a high degree of information 
integration across the enterprise and among business partners. However, information 
integration capabilities are evolving within industry and, as each CITIS application is 
initiated, it will be necessary to establish baseline integration requirements and allow for 
improved integration as the program progresses and new technologies become available. 
Therefore, the process to select specific functions and standards must be coordinated with 
contractors and government users throughout the program life cycle. [Ref. 28: p. 12] 

3. Relationship of JFCALS and CITIS. 

The government infrastructure being developed and the CITIS are viewed as 
complementary concepts. The JCALS system provides the preferred government gateway 
to contractor enterprises. The use of JCALS provides a known set of interface parameters 
(i.e., data elements. Global Data Dictionary and Directory (GDD/D), interface protocols, 
etc.). This will allow acquisition managers to easily construct "Government Concept of 
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Operations" (GCO) for their programs that will provide consistent and cost-effective 
solutions over the defense system life-cycle. [Ref. 8: p. 35] 

JCALS system specifications indicate the following four options for bi-directional 
CITIS interface (see Figure 3-2): 1) non-interactive data exchange using removable digital 
media; 2) selected CITIS functions using dial-up or network access capabilities; 3) on-line 
interface where data dictionaries are mapped to each other for transparent, seamless 
access; and 4) fully integrated, JCALS site-type interface for which the contractor is 
furnished GDD/D services, software and, if required, equipment (dependent on the 
infrastructure already in place at the contractor's site). 

As the JCALS system evolves, the acquisition manager should consider 
implementing the fourth option of JCALS/CITIS interface as the most assured 
methodology of achieving compatibility. However, if the cost-effectiveness of this strategy 
is prohibitive, then providing the contractor with compatibility guidance to achieve the 
third option of JCALS/CITIS interface is recommended. Either strategy will ensure that 
the interface is streamlined and standardized; minimize the problems incurred by an 
acquisition manager requiring access to multiple CITIS systems; provide for easier 
technical information download/transition to JCALS; and ensure the uniformity of 
software tools. Option 3's interface is achievable through adherence to the compatibility 
standards in Appendix A which are based on the TRM and CALS standards. Most 
important of these standards are the data dictionary standards. JCALS is in the process of 
submitting data elements for standardization through its Functional Data Administrator 
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(FDA) and Defense Information Systems Agency (DISA). These data elements will be 
documented in the JCALS data model and its Data Element Dictionary. Options 1 and 2 
represent the least sophisticated types of CITIS connection, and have several inherent 
drawbacks (among them are potential delays in receiving timely technical information). 
Acquisition managers should determine which CITIS options will be implemented based 
on a business case analysis to be documented in the GCOs for their programs. 
[Ref. 8: p. 37] 
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IV. APPLICATION FOCUS AREA 


In the JCALS world program, only the TM/TO functionality has been validated on 
a joint service basis. The Army Strategic Logistics Agency is now coordinating with the 
Services to reach agreements on other functionalities. It appears that in the near future 
Logistic Support Analysis and Engineering Change Proposals, among others, will be 
added to the program. [Ref. 13] This chapter will present some examples of those areas. 
TM functionality is almost done and DoN described it in the Navy/Marine Corps 
Manager's Desktop Guide for CALS Implementation. 

A. TECHNICAL MANUAL 

The first target of the JCALS is the hard copy Technical Manuals (TMs) or 
Technical Orders (TOs). PM JCALS is developing techniques through which to digitally 
manage, acquire and improve these documents and produce digitally reproducible masters. 
From the example of PHD NSWC, Technical Manual development and publishing is the 
only logistic functional element currently available on JCALS. 

1. Introduction 

Technical Manuals (TM) are publications that contain instructions for the 
installation, operation, maintenance, and support of defense systems, defense system 
components, and support equipment. The digital environment for the creation, 
management, and use of TMs based on CALS standards is essentail for transitioning from 
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paper-intensive defense system acquisition and support processes to automated and 
integrated digital processes. 

The Department of Defense (DoD) CALS strategy is designed to promote the 
digital creation, management, and use of data in the acquisition and support of DoD 
systems. CALS is not a single system, but rather a philosophy that emphasizes process 
improvement and the application of information technology to those processes for the 
purpose of digital sharing of data. This includes the data generated by the processes 
required to develop and maintain the TMs. One goal of CALS is to ma ximiz e the reuse of 
data throughout the product life cycle. An effective way to meet this goal is to design and 
implement processes that are supported by computer tools. The computer tools create 
reusable data that can be exchanged electronically to optimize the process. The CALS 
strategy encourages well defined processes that use computer tools for enterprise 
integration. Information architectures based on CALS strategies enable contractors, 
customers, and government agencies to share data, in real time, to design, develop, 
manufacture, distribute, and service products. Processes and computer tools, following 
CALS strategies and information technologies, reduce time-to-market and cost, and 
increase quality and performance. [Ref. 11, p 10-5] 

2. General Considerations 

The development of a CALS strategy for TMs needs to be carefully examined to 
ma ximiz e the value for a specific defense system program Program attributes such as 
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technology, costs, quantities, and schedules have a profound effect on the delivery 
requirements for TMs. The technical data Logistic Element Manger (LEM) must consider 
the life cycle of the procurement and the infrastructure in place or being developed to 
support the TMs for their program. 

TMs are any technical publication or other form of media used to install, operate, 
maintain test, repair, overhaul, or provide logistic support of ships, aircraft, defense 
systems, or defense material. TM data may be presented or delivered in any media 
including, but not limited to, hard copy, audio and visual displays, on-line access, magnetic 
tape, discs, and other electronic devices. [Ref. 11, p 10-10] 

a. Identify/Establish the Requirement for the TM 

The technical data LEM will first identify the requirement to procure a TM 
through the development of overall supportability goals and the initial maintenance 
philosophy. This is brought about through the Logistic Support Analysis (LSA) process. 
The LSA process will quantify and define requirements such as the need to operate or 
perform maintenance on equipment. The Logistic Support Analysis Record (LSAR) will 
contain the necessary task narratives for the operation and maintenance of equipment and 
will be used as the primary source for the development of technical manuals of various 
types. [Ref. 11, p 10-12] 
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b. Identifying the TM User's Requirements 


The technical data LEM must now identify the intended TM user's 
infrastructure. The users include those involved in system acquisition, review, and 
approval, the TM management infrastructure and the end user. The technical data LEM 
should consider the existing and planned infrastructures for both government and 
contractor facilities; available CALS data exchange standards; and the various digital data 
deliverable options in terms of media, format, and access. Documentation of this 
infrastructure review will take the form of a Government Concept of Operations (GCO), 
and will include: 1) the hardware and software systems the Government has, or is 
developing, to manage and use the data; 2) data users, types of data, frequency of use, and 
timeliness of data access or delivery to each user; 3) data use and the review and/or 
approval processes to support life cycle functions; 4) users' locations and their primary 
functions in support of the defense system; 5) data interchange requirements including 
format, media, applicable standards, and existing telecommunications capabilities; 6) 
access authorizations and restrictions; 7) data acceptance requirements including data 
format and content of data and the government process for accepting product, 
processable, or Contractor Integrated Technical Information Service (CITIS) data; and 8) 
digital data resources or source data (libraries of historical data, standards, and 
specifications) available to support program acquisition and logistics processes. 

Acquisition requirements for user hardware and software to support a 
fielded defense system are normally under the funding discretion of the technical data 
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LEM and must be considered during the CALS implementation strategy and planning 
process. [Ref. 11, p 10-12] 

c. TMs in the CALS Environment 

The technical data LEM should be aware that it is possible to acquire TMs 
in a variety of forms depending upon the needs of the users. Documents such as 
maintenance manuals may be highly beneficial when procured as Interactive Electronic 
TMs (EETM). The IFTM user would be the technician whose main concern is finding the 
desired ma intenance-related information quickly and easily without being burdened in the 
field with the entire maintenance manual. Description, operation, and maintenance, and 
installation and checkout manuals, however, may be procured best in raster or Page 
Description Language (PDL) since these manuals are not used as often. Obviously, it is 
better to leave these decisions up to file individual program office since each defense 
system program is unique in its requirements. 

Pr ima ry considerations for the technical data LEM to address when 
applying CALS to the creation, management, and use of TMs is the media, format, and 
content of TM data deliverables and their respective end users. 

Paper, microfiche, and microfilm have been included in this discussion of 
CALS because much of the TM inventory is still available on these media. The benefits 
associated with using digital data far exceed the costs. For TMs some benefits of digital 
data include: (1) improved handling and reduced storage of TM data with electronic filing 
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and archiving; (2) reduced costs associated with printing and distributing TMs by 
providing on-line access to the TM data, so that personnel could access the data 
repository from their field activity and view and/or print the specific TMs they require; and 
(3) improved accuracy and timeliness of the TM data, due in part to the simplified 
incorporation of change pages. [Ref. 11, p 10-14] 

3. Life Cycle Considerations 

TMs are generally not required until the later acquisition life-cycle phases of a 
defense system program. TMs available during the earlier phases may he preliminary 
copies that have not been verified or have not received final acceptance but are useful for 
test verification, training, and operation. Final Reproducible Copies (FRC) are available in 
the later phases. The technical data LEM must consider the information volume and 
typical use of the data generated during each of these phases to determine the appropriate 
TM deliverable format. Note that the deliverable format may be different for each phase 
(e.g., preliminary versions delivered in mutually-agreeable word-processing format and 
FRC s in SGML format). [Ref. 11, p 10-16] 

4. Contract Data Requirements Lists (CDRLs) 

Delivery of defense system data in digital form requires changes to the solicitations 
and contracts including their attachments and enclosures. These changes should be made 
with full consideration of the ability of defense activities to make cost effective use of 
digital data deliverables or access. Each defense system program may include unique 
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requirements for which additional program-specific tailoring will be needed. Most of the 
applicable CALS standards and specifications contain contract-negotiable options from 
which the technical data LEM must choose to satisfy program-specific requirements 
including multiple classes or types of data formats. 

The TM Contract Requirements (TMCR) will identify the types of TMs required 
and include language that specifies exactly how data will be delivered (including media, 
format, and content) under the contract. CALS standards should be invoked whenever 
possible for digital delivery of support products such as engineering drawings and TMs. 
The media for delivery such as magnetic tape, optical disk, or on-line (networks, telephone 
modems, CITIS) should be compatible with Government receiving system capabilities. 
Some digital deliverables, especially interim deliverables, may be efficiently acquired by 
agreeing on a common word processing package in the contract and specifying the 
appropriate and compatible physical media such as magnetic disk, magnetic tape, etc. 
[Ref. 11, p 10-16] 

5. Interactive Electronic TM (IETM) 

An IETM is a computer-based collection of information needed for the diagnosis 
and maintenance of a defense system It is optically arranged and formatted for interactive 
presentation to the end user on an electronic display system Unlike other optical systems 
that display a page of text from a single document, IETMs present interrelated information 

from multiple sources tailored to user queries. 

Specifications for defining IETMs include: 
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• MIL-D-87269, Database, Revisable: Interactive Electronic Technical 

Manuals, for the Support of 

• MIL-M-87268, Manuals, Interactive Electronic Technical: General Content, 
Style, Format, and User-Interaction Requirements 

• MEL-Q-87270, Quality Assurance Program: Interactive Electronic Technical 
Manuals and Associated Technical Information; Requirements for 

An IETM is essentially a hypertext document, which consists of a collection of 
"interconnected writings." These interconnections allow a user to browse through a 
document by selecting points of interest or hot spots that may be connected to other 
related text, hot spots, or menus. The user could then continue to follow along these 
"paths" to other cross-referenced points in that collection of writings. This creates a 
"pageless" document that, depending on the source database, can contain a collection of 
information from a variety of sources. Also, rather than limiting these documents to pure 
text, we may incorporate graphics, audio, video, and/or computer programs into the 
content of the document, creating what is known as a hypermedia document. 

By streamlining access to the desired information and by providing multiple paths 
to other related information, the IETM offers a more efficient and more comprehensive 
method of using technical information. Unrestricted by the page-oriented display and the 
use of sole-source information, the IETM duplicates on the Personal Computer (PC), the 
research environment available in a well-equipped multimedia library; displays only the 
actions appropriate for resolving a specific problem; provides fault-isolation tables and 
diagrams; and guides the technician through the troubleshooting process via a 
user-friendly query method. IETMs permit the user to locate information more easily and 
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to present it faster and more comprehensively in a form that requires much less storage 
than paper. [Ref. 11, p 10-22] 

a. IETM Viability 

The technical data LEM should consider whether the TM will ultimately be 
used in an interactive computer environment, the IETM. The IETM format offers the user 
distinct advantages over the traditional TM. Some IETM benefits include: 1) reduction in 
the false removal rate of Line Replaceable Units (LRU) or Weapon Replaceable 
Assemblies (WRA); 2) reduction in troubleshooting time; 3) reduction in the TM support 
costs associated with distribution, management, and storage; and 4) allowing training 
activities to concentrate more on generalized training versus system specific training. The 
te chnic al data LEM should first determine whether the end item or defense system 
program is currently in the early phases of design, whether the life cycle requirements for 
the TM exceed five years, and whether the Technical Data Package (TDP) or LSAR 
database contains, or can be economically altered to include, a numbering system similar 
to MIL-STD-1808. If any of these considerations can be answered "NO," then an IETM is 
not recommended. If all considerations can be answered "YES," then a business case 
analysis should be performed to determine the economic feasibility of the IETM. If results 
from this analysis recommend pursuing an IETM or quality readiness and/or support 
factors lend adequate credence to the need for an IETM, development of an IETM should 
be pursued. In this case, develop IETM. [Ref. 11, p 10-23] 
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b. IETM Development 


Once IETM development has been decided, the technical data LEM must 
first determine whether this effort will be associated with an existing IETM in terms of 
either the modification of an existing IETM or the creation of a supplement to an existing 
IETM. If this is indeed the case, then the technical data LEM must determine whether an 
existing infrastructure and display device will be used in conjunction with the IETM and 
whether this infrastructure uses a proprietary format. If all of the above conditions are 
true, then the final IETM developed should remain in the existing proprietary format. 
However, if any of these conditions is not met, then it is advised that the IETM be 
developed using the new IETM standards. [Ref. 11, p 10-24] 

B. LOGISTICS SUPPORT ANALYSIS (LSA) 

This section presents about LSA. LSA has not been validated by all joint services 
yet. But it has been tested in prototype sites. The Army Strategic Logistics Agency is 
coordinating with the Services to reach agreement on this functionality. Followings are 
from the Guide of DoN. 

1. Introduction 

Logistics Support Analysis (LSA) is a systematic and comprehensive analytical 
process that is conducted on an iterative basis through all life cycle phases of the 
system/equipment. LSA is for quantifying and measuring supportability objectives 
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(supportability includes all elements of Integrated Logistics Support (ILS) required to 
operate and maintain the system/equipment.) Depending on the level of tailoring, 
extensive amounts of information and data are required as an input to, and generated as a 
result o£ the LSA process. The LSA process fits into the ILS process as LSA tasks are 
planned, initial front end analyses are performed, and LSA information is generated. 

LSA information consists of all data resulting from the analysis tasks conducted as 
defined in MIL-STD-1388-1A and is intended to be the primary source of validated, 
integrated, design-related product support information pertaining to an acquisition 
program LSA information is developed and maintained as a result of design, support, and 
operational concept development and is updated to reflect changes. 

LSA Record (LSAR) data is a subset of LSA information and is a structured 
means of aggregating LSA data. It is available for use by all services and ILS element 
functional areas. Because each element of LSAR data is defined and has a specified data 
structure, the LSAR has evolved as the primary means of storing logistic support data in 
digital media. [Ref. 11, p 11-5] 

2. CALS and LSA by Functional Activity 

Considerations that must be addressed when an Acquisition Manager is acquiring 
LSA data in digital format include: 1) specifically who will use the data?; 2) what 
hardware and software are needed to use it?; 3) will the digital data be applied directly or 
as source information for the follow-on products?; and 4) are there digital data sources 
available that can be used as input to the LSA process if source data is available, who has 
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it, what form is it in, and are there any challenges associated with providing it? These 
considerations, to various degrees, must be addressed by the Acquisition Manager for and 
within each of the three major activities (create, manage, and use) associated with LSA 
data acquisition. [Ref 11, p 11-7] 

3. Current Considerations for the LSA Process in a CALS Environment 

The four prime factors that govern system acquisition programs are cost, schedule, 
performance, and supportability. The LSA process provides direct input into the 
supportability and cost factors associated with a system/equipment and, therefore, 
provides significant input into system/equipment decisions. The CALS environment offers 
the opportunity through digital application of the LSA process for reductions in Life Cycle 
Cost (LCC). The ability to create data once (including LSA, engineering, and ILS data) 
and use it many times impacts the cost of the LSA process and the follow-on support 
costs. If the LSA data and associated analyses (FMECA, RCM, etc.) are created in a 
digital format, then digital data required for the LSA can be linked and fed to the LSAR 
database in an automated fashion. The initially created LSA data is then available for use 
in all technical data products. The Acquisition Manager must consider the digital format, 
media, HW/SW issues, required framework, architecture, and Government infrastructure 
when developing the Government Concept of Operations (GCO) concurrently with 
selecting LSA tasks. [Ref. 15, p 11-16] 
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4. Future Considerations for the LSA Process in a CALS Environment 


This paragraph will present some thoughts on where CALS is headed and how that 
might affect data use in the future. The influence of infrastructure developments in the 
Navy, within the DoD, and even in the international community will all affect the potential 
environment in which the LSA data acquired now may have to be used in the future. [Ref. 
11, p 11-25] 

a. Integrated Weapon Systems Database (IWSDB) 

Future trends must lead to and support the fundamental objective of CALS, 
which is to lower costs to the Government, improve quality, and shorten lead times. The 
electronic sharing of data allows it to be created once and then used by multiple users, 
multiple times. The integration of functional processes will start with the integration of 
data. The acquisition strategy must specifically address the automation and integration of 
technical information systems and functional processes. 

The process for determining LSA data and LSAR database requirements is 
an extension of the process currently used for determining data requirements, selecting 
appropriate data items, and developing the Contract Data Requirements List (CDRL) that 
identifies the requirements. The LSA/LSAR databases are the building blocks that are 
necessary to support an IWSDB. The process for determining LSA data and LSAR 
database requirements may evolve as the requirement for access to the data intensifies. 
There is significant potential for reduction of data requirements in that, with query 
capability, the Government can generate data, reports, and products on demand rather 
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than having the contractor prepare and deliver them. As digital data utilization evolves, the 
media on which the data is delivered will also evolve as depicted on Figure 11-9. 
[Ref. 11: p 11-24] 

b. Contractor Integrated Technical Information Service (CITIS) 

Access to digital data will become the standard by which all acquisitions 
will be measured. Because CITIS provides access to contractor-managed, 
functionally-integrated information, it must play a significant role in improved Government 
operations and the streamlining of processes. An effective CITIS program will require 
foresight and added coordination efforts on the part of contractors. Government sponsors, 
and potential CITIS users. Functional integration approaches, as well as CITIS 
performance, must be considered. Measures should be developed to motivate contractors 
with top-level commitments to produce overall, functional integration and an effective 
CITIS implementation. 

An effective LSA program will be planned, integrated, developed, and 
conducted in conjunction with the requirements of the overall acquisition program 
objectives. The LSA process will be established consistent with the type and phase of the 
acquisition program To maximize the use of the plans, procedures, front-end analyses and 
reports developed from selected LSA tasks, it is necessary to establish a viable 
communication link with the contractor. Providing an early-on CITIS capability (including 
analyses and documentation generated from the 200 & 300 series tasks of 
MEL-STD-1388- 1A) will enhance the LSA process and the overall design effort. 
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There are several considerations facing contractors when they are tasked 
with providing CITIS to support LSA databases. Areas of consideration include the 
following. 

• Type of DBMS or languages: The number and disparity among 
database management systems, programming languages, data models, 
data descriptions or data organizations, and interface and access 
languages; 

• Data element format: The number of discrete techniques for re 
formatting data to be presented to the user in a predefined, standard 
format including conversion of units of measure, translation into 
standard format, and other agreed upon translations or conversions; 

• Source or location of data and applications: The user must know the 
differences concerning location, hardware, operation system, 
programming language, and access methods for specific systems; 

• Relationship and dependencies: The degree to which the user must 
keep track of data relationships and dependencies within and across 
integrated data sets; 

• Version knowledge and control: The degree to which the user must 
ensure that data retrieved from more than one system and database are 
consistent in terms of data values, version or status, and context. 
[Ref. 11: p. 11-25] 


C. ENGINEERING DATA MANAGEMENT SYSTEMS 

This section includes two real life examples of improvements and benefits 
introduced by implementation of CALS in both industry and government engineering 
document management systems. [Ref. 29: p. 10] 


87 



1. ECARDS 


General Dynamics (GD), Land Systems Division located in Warren, Michigan has 
over the past four years implemented the Engineering Computer Aided Retrieval and 
Distribution System (ECARDS) that is an information management system for raster 
image data. General Dynamics builds tanks for the U.S. Army and foreign governments. 
With the implementation of ECARDS, GD has taken the first step in moving toward a 
paperless production of a defense product: the M1A1 Tank. The current paper based 
M1A1 repository is being scanned into the system from both paper and aperture card 
originals. Images are being stored digitally onto optical disk. The system is completely 
computer controlled, automatic, and has the capability of providing audit logs for the 
tracking of image file retrieval and printing. The system also has access security built into 
the user interface application. ECARDS utilizes the MIL-R-28002, Type II CALS 
standard for all image files. This raster data format known as TRJOF (Tiled Raster 
Interchange Format) is tiled on 512 pixel boundaries and compressed via the CCITT 
Group IV compression standard. Currently the ECARDS system is limited to storing and 
retrieving only raster image data. The next step in the evolution of ECARDS is to 
incorporate both CAD, vector files and technical publishing files. These formats will be 
implemented using the IGES and SGML standards respectively. 

Also recently implemented within ECARDS is the ability to transfer image data to 
and from the government. The U.S. Army Tank Automation Co mma nd (TACOM) is the 
General Dynamics' largest customer. TACOM has implemented a system called DSREDS 
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for (Digital Storage and Retrieval Engineering Documentation System). It is now possible 
for a user of the ECARDS system to send image data, drawings, and documents to the 
DSREDS system electronically. Also, a user of the DSREDS system can automatically 
access the ECARDS database to search for and retrieve image files electronically. 
TACOM users can accomplish this by remotely accessing a 3270 terminal emulation 
session with the IBM mainframe computer at General Dynamics and interacting with the 
configuration management application. The second step is the ordering of the desired 
image file or series of files, upon system approval, through an X-windows user interface 
session that interacts with the ECARDS storage and retrieval application. The 
co mmuni cation media between systems can be a T1 leased line or an internet network. 
This capability - government access of contractor database - is an example of CALS 
phase n Contractor Integrated Technical information Services (CITIS) implementation. 
This is just the first step in fully implementing a complete paperless data interchange 
environment. This project shows how progress is being made to accomplish the goals of 
CALS objectives in a step by step fashion. [Ref. 29: p. 10] 

2. HSTTMIS 

The Technical Management Information System (TMIS) at the NASA, Goddard 
Space Flight Center in Greenbelt, Maryland is in the process of being upgraded to support 
CALS standards. At Goddard, TMIS is used as a complete engineering data management 
system for the Hubble Space Telescope (HST) project. TMIS is being used as a repository 
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for all relevant engineering data and technical documentation related to the design, 
maintenance, and support of the HST. The HST TMIS operation is a real life example of 
what problems occur when an engineering document management system is implemented 
according to CALS specifications. 

In the past, TMIS consisted of many different databases (one for drawings, one for 
documents, and others for engineering changes, parts lists, etc.). In order to successfully 
implement a system that is capable of electronically storing and controlling HST data 
many things must be done up front. First, the data must have a high degree of integrity; 
the drawing and document database indexes must match the data. Second, there must be 
a means of accessing all relevant databases from one system Third, vendors who supply 
documentation in support of their products must be willing to supply information via 
standard electronic means. Fourth, data must be converted to digital form before a full 
system can be implemented and used. 

In the recent past vendors would take product data, engineering drawings, support 
documentation, training material, repair material, etc., (most of which was generated in 
electronic form), and send it to the HST TMIS operation in paper form At that point 
TMIS operators would be required to digitize this information, index it, and store it in 
digital form within the TMIS system This involves (1) going from a digital form (CAD 
and Word processor generated data) to (2) a paper form, and back to (3) a digital form for 
input into the system. The costs of this redundant and unnecessary re-digitizing of 
documentation is what CALS is trying to minimize. TMIS managers are in the process of 
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e liminatin g this problem by adopting the capability of accepting data electronically from all 
vendors. This capability alone will save substantial costs associated with the printing of 
images, the transportation of printed material, the indexing of the material, and the 
scanning and digitizing of the material, not to mention the costs of the equipment 
necessary to do this work. 

The goal of HST TMIS managers is to get to a point where all information 
associated with the HST products can be transferred and accepted electronically through 
the use of CALS standards. The TMIS system uses the MIL-R-28002, Type II (TRIF) 
data standard for raster image data. TMIS has the ability to convert TRIF data files to and 
from other industry standard formats and some that are proprietary in nature. The HST 
TMIS system is being upgraded with application software that allows for a complete 
CALS compliant solution by incorporation of off-the-shelf software application programs 
into the system TMIS can store, retrieve, and control any type of file (raster, CAD, tech 
pubs, CGM illustrations, etc.). 

HST, TMIS managers have found that supporting CALS standards within your 
organization or system is only half of the problem Many problems have been identified in 
the process of implementing this capability. Requiring the various vendors who supply 
product data (sometimes hundreds of companies) to supply data in one common format 
(CALS compliant or not) has proven to be a very difficult thing to do. For example, of the 
main HST suppliers of information, which consists of approximately seven companies 
Lockheed Missiles and Space Company, Ball Aerospace, Electro Optics Cryogenics 
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Division, Hughes Danbury Optical Systems, the University of Arizona, and the European 
Space Agency, has a different type of CAD system that is used to generate engineering 
data. It has was discovered by HST, TMIS managers, through a painful process, that the 
Initial Graphics Exchange Specification (IGES) standard is not supported in the same 
manner by each CAD system and software vendor. This means that IGES files written by a 
particular application may not be readable in its entirety by a second vendor MES 
program. In most cases, character and notation data is what drops out upon electronic 
data interchange between systems. This data is only recovered by manual means via labor 
intensive quality control; this is a costly proposition. This problem can only be solved with 
time, better definition of the standard, and incentive on the CAD manufacturers to 
implement and/or upgrade field software with CALS compliant versions. It will become 
increas-ingly more important to each of these vendors as more and more government 
contracts require CALS compliancy in the future. [Ref. 29: p. 11-12] 
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V. RECOMMENDATIONS FOR THE ROK ARMY 


A. LESSONS FROM U.S. CALS 

CALS started as a program that managed several Information Technologies (ITs) 
to achieve greater efficiency in the acquisition and logistics businesses. Effectively 
managing IT inherently implies managing change. The ongoing technological revolution 
within this field shows no sign of abating. IT mangers are subject to the same forces that 
are forcing change in other area, and are themselves responsible for one of these driving 
factors of change within business and society. Therefore, much of the writing on 
implementing IT focuses on change. Furthermore, IT projects like CALS permeate every 
functional area of the organization, so their changes inevitably require organization-wide 
adaptation. 

One of a mana ger's critical concerns is IT integration. Integrating IT covers two 
topics. The first is de signing the system so that it is supportive of the enterprise wide 
goals. The second is the actual implementation of new systems. Both can be accomplished 
through a common approach. Carol Beatty has identified the factors involved in doing this 
successfully. She identifies three factors: 

• An effective champion. Usually someone with some backing from senior 
mana gement, this person must especially have the political skills to negotiate 
among the various coalitions that exist across functional lines. 

• A plan for system integration. As self evident as this may seem, only about half 
of the firms implementing new IT systems have any plan at all for tying 
together the systems of their firm Indications are that the most successful 
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method to date for formulating and implementing these plans are through 
cross-jurisdictional committees and teams. 

• Steering committees and implementation teams. Because of the complexity and 
interrelatedness inherent in an information system that spans all aspects of an 
organization, it is unlikely that any one person would have all the expertise and 
insight to design an optimum system Even if they did, they would than face a 
daunting task educating and gaining the support of the many diverse coalitions 
that exist in any large organization. Steering committees exist at the senior 
management level with a medium to long range time frame. They are primarily 
responsible for integrating the IT effort it the organizations overall strategy. 
The implementation teams represent the users of the system, they are involved 
in the nuts and bolts of the actual system development. [Ref. 30] 

Based on this theoretical framework, I would like find some lessons from the U. S. 
CALS effort. 

1. An Effective Champion 

CALS has received support from senior leadership, both the President and the 
Secretary of Defense. Since September 1985, when CALS was initiated by a memorandum 
of the Deputy Secretary Defense, Taft, there were several efforts to embed the purposes 
of CALS in the DoD. At the beginning, the formalizing of the acquisition process by DoD 
Instruction 5000.2 helped to institutionalize infrastructure modernization by JCALS and 
Joint EDMICS programs and CITIS development. [Ref. 31: p. 48] Recently in October 
1993, President Clinton's memorandum made the use EDI mandatory in new procurement 
systems being developed across all federal agencies. 

A change champion was formally organized as PM JCALS which was definitely a 
benefit. Unfortunately, the actions of some of their personnel endangered the program, 
highlighting the need for high quality, well trained people to manage it. 
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2. A Plan for System Integration 


As is the case with many large IT projects, the lack of clearly defined requirements 
proved to be problematic. In its report, the Government Accounting Office (GAO) 
criticized JCALS implementation. "There is great uncertainty as to whether JCALS will 
meet user needs," GAO said. The services, the report noted, have not reached a 
consensus on format and data content requirements for the technical manuals. According 
to report, Dr. Tomlinson, PM JCALS program manager, said it probably would take two 
or five years to come to such an agreement. [Ref. 32] 

The Pentagon CALS office said "We understand the need to clearly define the 
CALS initiative and what it encompasses. We have defined the initiative very clearly in the 
CALS Phase II Architecture Deployment Plan, which is expected to be circulated by the 
beginning of the calendar year." [Ref. 32] 

Another common problem in IT projects is that of requirements creep. Since 
CALS's inception in 1985, it has undergone several transformations. DoD intended to 
computerize the technical and logistics data for weapon system development. In its 
current form, CALS encompasses the entire life cycle of weapon systems. 

GAO said, "Although DoD has expanded the CALS scope, the department has 
failed to define the initiative and its implementation. Despite the significant potential 
benefits offered by CALS, there is no single point of accountability for the initiative. 
Instead, management responsibilities are diffused throughout government and industry." 
[Ref. 32] 
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One very positive lesson learned from the U.S. experience is the importance of an 
evolutionary approach to the acquisition through the use of prototypes for 
implementation. As aforementioned earlier, DoD estimated a need for over 250 JCALS 
sites over the world. DoD has tested 6 prototyping sites and Dr. Tomlinson said this : 
"The Joint Computer-aided Acquisition and Logistics Support (JCALS) program has 
successfully employed prototyping as part of its evolutionary acquisition strategy. The 
incorporation of prototyping into the JCALS acquisition strategy is not only a sound 
design/development methodology but is consistent with the DoD guidance in 
DoDI 8120.2. Guidelines in this policy instruction show that prototyping may be used 
throughout the life cycle management process. The prototyping concepts provide an 
opportunity to significantly reduce risks to the JCALS program and to provide better 
responsiveness to the users of the JCALS system" [Ref. 33] 

3. Steering Committees and Implementation Teams 

Good use has been made of steering committees at DoD and DISA, and 
implementation teams in NIST and industry. Within DoD, the CALS & EDI Office of the 
Under Secretary of Defense (Acquisition and Technology) is responsible for issuing CALS 
directives and coordinating CALS efforts among DoD military departments and agencies. 

The Defense Information Systems Agency (DISA) is responsible for maintaining 
DoD information technology standards and conventions. Within DISA, the Center for 
Standards, part of the Joint Interoperability and Engineering Organization, is the 
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designated configuration manager for DoD Electronic Commerce/Electronic Data 
Interchange (EC/EDI) standards. [Ref. 34] 

The National Institute of Standards and Technology (NIST), a part of the 
Department of Commerce, has been tasked to provide the DoD assistance in developing 
the CALS standards. NIST works with military departments and agencies, industry and 
national and international standards organizations to develop the CALS initiative 
standards and make recommendations to the CALS and EDI Office on which standards to 
implement. 

The CALS initiative being, a joint DoD-industry program, is primarily represented 
by the CALS Industry Steering Group (ISG). The CALS ISG leadership has recently 
renamed the CALS initiative to Commerce at Light Speed to better reflect the ISG’s 
opinion that CALS strengths rest with Enterprise Integration (El) efforts in 
manufacturing. 

The CALS ISG has formed Regional Interest Groups (RIGs) to meet periodically 
with industry representatives to keep them current with the latest CALS developments. 
At the time of this writing there are CALS RIGs in at least 25 states. [Ref. 7: pp. 11-13] 

At the seventh annual CALS conference and exposition on December 6, 1994, the 
CALS ISG Executive Advisory Council announced the formation of CALS International. 
CALS International will serve to advance international business by promoting the use of 
standards and shared digital data in electronic commerce. Presently, there are nine nations 
with CALS ISG organizations: United States, Canada, United Kingdom, France, 


97 



Germany, Sweden, Japan, Taiwan, and Australia. Additional countries are expected to 
formalize a CALS organization with the announcement of CALS International. 

The CALS International will consist of three elements: 1) International Board of 
Directors (like a steering committee), responsible for setting priorities, defining long-range 
objectives and forging strategic partnerships and cooperative relationships; 2) the 
International CALS Congress (like an implementation team), responsible for developing a 
coordinated approach to implementing CALS requirements; and 3) the International 
CALS Secretariat, responsible for providing staff support. 

4. CALS Culture Shock 

Schein identifies the introduction of new technology as a cultural change problem. 
Benjamin and Blount further indicate that organizations have often not reaped the 
promised benefits because they have not understood the need to develop new processes 
when developing new systems. Implementing IT is an organizational change problem, and 
can be successful only when senior executives are willing to pay the price that complex 
cultural change entails. [Ref. 35: pp. 36-38] 

Secretary of Defense Taft envisioned the bold nature of CALS as a 25-year 
infrastructure modernization and process improvement effort — changing the way we do 
acquisition and logistics. The enabler of that change is the infusion of information 
technology and the business process re-engineering concepts driving today’s changes in 
information management. Whether one views these changes as evolutionary or 
revolutionary is a matter of perspective. Regardless of perspective, CALS involves 
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change! This change has caused the creation of a culture shock within the acquisition and 
logistic communities of both government and industry. Certain skills will become obsolete 
and new skills will be developed. These changes trigger both fear and excitement in 
people, depending upon their individual assessments of how they fit in the future. [Ref 
31] 

In their article, in 1993, Davidovich and Heisterberg said CALS culture shock is 
the result of three discontinuities of understanding between those who see the impact of 
CALS upon government and industry and those who see CALS as a just another fad or 
don't even know what the CALS acronym means. They added three reasons of 
discontinuity; 1) people using the "CALS Military Standards" for an explanation of CALS 
while others use the various CALS policy statements; 2) resistance by other IT projects 
from being absorbed into the CALS effort; and 3) CALS advocates who have created an 
ever increasing and complex CALS lexicon. 

Even one of the most advanced countries, the United States, has experienced the 
cultural shock from this change which they prepared and faced; Korea, a developing 
country, could also expect these cultural shocks. 

To reduce CALS culture shock, they suggest types of actions that are grouped 
into three themes: education, management, and funding. 

Education weakens culture shock by establishing a common understanding of 
CALS. Group consensus is a visible indication that culture shock is being reduced -- 
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focusing the group to communicate and exchange their problems and solutions on 
information technology and process improvement matters. 

Management has many paths to attack culture shock - establishing a testbed for 
evaluating, demonstrating and rapidly prototyping CALS/CITIS applications. CITIS 
offers managers an excellent and practical environment to deal with and overcome CALS 
culture shock. 

Funding is the ammunition that quells culture shock - advocating funding with a 
focus on a business case, starting a CITIS business case to develop the needed supporting 
data, and establishing a relationship with DoD laboratories dealing with information 
technology. [Ref. 31] 

B. STATUS QUO OF KOREAN CALS 

Now, the interest in CALS is increasing in Korea, i. e., several newspapers 
introduced CALS, its benefits, successful examples in other countries and the urgency of 
the implementation in Korea. But this interest on the industry side is greater than on the 
government side. 

Now, in Korea, the CALS Committee of the EDI Office of the Computer and 
Communication Promotion Association of Korea (CCPAK) plays the leading role for 
CALS activities on the industrial side. Most of the large industrial conglomerates 
(Samsung, Hyundai, DeaWoo, Lucky-Goldstar, Oracle System Korea, and etc.) has 
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started studies focusing on CALS. CCPAK has held "CALS Korea : the International 
Conference & Exhibition" in 1994 and 1995. 

On the government side, the Ministry of Information & Communication (MIC) and 
the Ministry of Trade, Industry & Energy (MTIE) have established long term plans for 
CALS. In February 1995, MIC announced that it will spend 100 Millions Won (US $ 
125,000) to establish the master plan for CALS that set out the Korean CALS vision and 
provide direction for a systematic push in this year. 

MIC will use this master plan as a basic guide line for the national CALS 
implementation and the plan to connect with the Industry Information Network project. 
They will also use it to create development plans to fit the character of the each industry. 

MIC plan to establish the "CALS Korea Co-operation Committee (CKCC, 
proposed)" from the CALS Committee of CCPAK with related institutes and associations, 
CKCC will analyze CALS related businesses, urge co-operation between associations and 
companies, and take a role for consulting and assisting international projects. [Ref. 36] 

Also MND is studying the issue to develop a basic plan for Korean CALS setup. 
More detailed plan will be developed by the Korea Institute for Defense Information 
System (IDIS). Additionally, the Agency for Defense Development (ADD) will develop 
an Integrated Weapon Systems Data Base (IWSDB) as a model for the services. 
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C. RECOMMENDATIONS 


This section presents some recommendations for a Korean CALS Implementation 

plan. 

1. Use The Prototype Implementation Strategy 

A prototype strategy will avoid the large sunk investment in rapidly changing 
technologies. Prototypes will train people and help overcome resistance and culture shock. 
This process can itself take years, so we need to start these processes early in our effort. 

The Korean Armed Forces (KAF) has a relatively small size compared to the 
United States'. Instead of one or two prototyping sites in each service, a joint prototyping 
site which has departments of each service could be tested and demonstrate several CALS 
projects on the same equipment. It could help avoid potential conflicts from use of 
different standards in each service from the beginning of the implementation. 

2. Exchange Personnel to Effect Technology Transfer 

Professor Thomas J. Allen from the Sloan School of Management at MIT did 
extensive research into the process of technology transfer under the sponsorship of the 
U.S. National Science Foundation. The main finding of his analysis, now widely accepted, 
is that the most effective way of transferring technology is through the relatively long term 
exchange of personnel. Personnel assigned to an outside organization establish a network 
of informal contacts outside of their native organizations and then tend to serve as 
"gatekeepers" who continue to bring fresh ideas into their organizations long after their 
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return. Personnel from outside the organization who come to work inside on a day to day 
basis, tend to stimulate a higher level of activity and exchange of ideas. [Ref. 37] 

Based on Allen's research, it would be available to exchange personnel between the 
U.S. and Korean CALS efforts, for example: 1) send liaison personnel from Korean CALS 
project Office to JCALS or DISA for long term assignment (1 to 3 years); 2) try to get 
some manpower from the U.S. ISG or a consulting contractor from the U.S. to work in 
Korea to establish a Korean ISG through CALS International. 

3. Establish Standards 

We found sufficient reasons why we should introduce CALS as soon as possible. 
Nowadays the Korean domestic defense industry already has some degree of capability to 
develop new weapon systems (e.g., K1 tank in Army, FFK, destroyer level of ship in 
Navy). Unfortunately, those developments were done without a frill architecture of the 
CALS consideration. Maybe some of the industrial CALS-compatible applications (e.g., 
EDI, SGML) are partially used by big businesses (not in the military project but in the 
business trade or other purpose) but not integrated together. The most problematic issue is 
that there are no documented standards for the CALS environment of Korea. Therefore 
the most urgent phase of the CALS implementation should be the establishment of 
standards. As the U.S. CALS standards set their direction for the international integration 
of CALS, it will be preferable for MND to follow the format of the U.S. standards. For 
KFP, at least five classes of standards are needed. Those are 1) SGML for the text 
standard, 2) IGES for the vector graphics, 3) CCITT Gr. 4 for raster graphics, 4) 
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M1L-STD-1388-2D for the logistics data, and 5) MIL-HDBK-59B for overall instruction 
about data acquisition and usage. 

4. Build Defense Information Infrastructure 

After the standards have been established, the real architecture design for CALS 
will be possible as the next phase of CALS implementation. For example, the three big 
contractors for the Korean Fighter Plane (KFP) could have the engineering data 
depository and other 100 subcontractors might have CALS network capability. For CALS 
data transmission, a 100 Mbps network capability is required. To acquire this transmission 
capability, the MND project launched recently might be done with optical fiber. When we 
consider the huge amount of the KFP investment, the cost of building the network is quite 
modest. Therefore, a good chance exists to obtain funding for infrastructure construction. 
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VL CONCLUSION 


The goal of CALS is to move from the traditional, paper-based organization to an 
integrated digital information-oriented enterprise. However, achieving this transition will 
require new management approaches and the cooperative involvement of the participating 
enterprise in solving current and future problems, such as organizational and cultural 
issues, legal and security issues, technology selection, and the integration of legacy data. 
[Ref. 2, p 58] 

The Government and the Military of the Republic of Korea, having recognized the 
potential benefits of CALS, is now in the process of defining its implementation strategy 
and plans. Additionally, MND is actively exploring CALS for the benefits described 
above, and to improve interoperability with Korea's military allies. 

The conclusion reached by this thesis research is that it will be a matter of how, 
rather than if, the Korean MND will incorporate CALS into its operations and 
infrastructure. The scope of CALS has grown to the point that it now represents the bulk 
of the information technology revolution as it unpacts on the materiel support of a modem 
military. 

Learning from the U.S. experience, we see that the challenges of CALS spring 
from both the technology involved and its pervasive organizational impact. 
Organizationally, it is important to involve all stakeholders in the process to address their 
concerns and achieve "buy in." To maintain discipline in the process a single arbiter must 
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be in charge and an explicit plan is required to coordinate the many diverse efforts. The 
impact of changing procedures and culture must he anticipated and addressed. 

The technological challenges of CALS descend from the rapid rate of change of 
the technology, and the difficulty of establishing standards. The long lead time required 
for infrastructure installation requires an early effort to build, but for other components of 
the system (e.g., processors, storage, display, and software) the use of prototype and a 
phased, modular procurement approach will allow a more cost effective way to benefit 
from incremental technological development. 

The definition of international standards is currently underway by the CALS ISG. 
It is concluded that it would be to the benefit of Korea to participate in this process by 
exchanging personnel. This would ensure that Korean requirements are included, such as 
Korean letter standards, and that Korea remains on the leading edge of technological 
development and military prowess. 
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APPENDIX: ACRONYM 


ADD 

Agency for Defense Development 

ADM 

Association for Information and Image Management 

AIS 

Automated Information Systems 

ANSI 

American National Standard Institute 

AP 

Acquisition Plan 

AP 

Application Protocol 

ARM 

Application Reference Model 

ARPANET 

Advanced Research Project Agency computer NETwork 

Ascn 

American Standard Code for Information Interchange 

ASME 

American Society of Mechanical Engineers 

BBS 

electronic bulletin boards 

CAC 

Contractor's Approach to CALS 

CAD 

computer-aided design 

CALS 

Continuous Acquisition and Life-cycle Support 
or Computer-aided Acquisition and Logistics Support 

CALS ISG 

CALS Industrial Steering Group 

CBC 

ConstructionBattalion Center 

CCPAK 

Computer and Communication Promotion Association of Korea 

CCITT 

Consultative Committee for International Telegraph and Telephone 

CDRL 

Contract Data Requirements Lists 

CD-ROM 

Compact Disk Read Only Memory 

CE 

Concurrent Engineering 

CGM 

Computer Graphics Metafile 

CIM 

Corporate Information management 

CITIS 

Contractor Integrated Technical Information Services 

CKCC 

CALS Korea Co-operation Committee 

COTS 

commercial-off-the- shelf 

DDN 

Defense Data Network 

DFARS 

Defense Federal Acquisition Supplement 

DB 

defense integrated infostructure 

DISA 

Defense Information Systems Agency 

DISN 

Defense Information Systems Network 

DLA 

Defense Logistics Agency 

DoN 

Department of Navy 

DoD 

Department of Defense 

DPS 

Defense Printing Service 

DSREDS 

Digital Storage and Retrieval Engineering Data System 

DTD 

Document Type Definition 

EAC 

Electrical Applications Committee 
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EC 

Electronic Commerce 

ECAT 

Electronic Commerce Acquisition Team 

ECARDS 

Engineering Computer Aided Retrieval and Distribution System 

EDCARS 

Engineering Data Computer-Assisted Retrieval System 

EDI 

Electronic Data Interchange 

EDIF 

Electronic Design Interchange Format 

EFT 

electronic funds transfer 

El 

Enterprise Integration 

EMD 

Engineering and Manufacturing Development 

FIPS 

Federal Information Processing Standard 

FOSI 

Formatting Output Specification Instance 

FDDI 

Fiber-Optic Distributed Data Interface 

FRC 

Final Reproducible Copies 

FTAM 

File Transfer and Access Management 

GAO 

Government Accounting Office 

GCO 

Government Concept of Operations 

GD 

General Dynamics 

GDMS 

Global Data Management System 

GD/DDB 

Global Dictionary/Directory Data Base 

GFI 

Government Furnished Information 

GO SIP 

Government Open Systems Interconnection Profile 

HST 

Hubble Space Telescope 

HTTP 

HyperText Transfer Protocol 

HUI 

human-user interface 

IGES 

Initial Graphics Exchange Specification 

IAW 

in accordance with 

1DIS 

Korea Institute for Defense Information System 

IETM 

Interactive Electronic TMs 

ILS 

Integrated Logistics Support 

IMS 

information management system 

IPC 

Interconnecting and Packaging Electronic Circuits 

IPO 

IGES/PDES Organization 

ISO 

International Organization for Standardization 

IT 

Information Technologies 

IWSDB 

Integrated Weapon Systems Data Base 

JCALS 

Joint Computer-aided Acquisition and Logistics Support 

JEDMICS 

Joint Engineering Data Management and Information Control 
System 

KAF 

Korean Armed Forces 

KIDIS 

Korea Institute for Defense Information System 

KFP 

Korean Fighter Program 

LCC 

Life Cycle Cost 

LEM 

Logistic Element Manger 
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LEP 

Layered Electrical Products 

LRU 

Line Replaceable Units 

LSA 

Logistic Support Analysis 

LSAR 

Logistic Support Analysis Record 

MIC 

Ministry of Information & Communication of Korea 

MND 

Ministry of National Defense of Korea 

MTIE 

Ministry of Trade, Industry & Energy 

MLS 

multi-level secure 

Nil 

national information infrastructure 

NIST 

National Institute of Standards and Technology 

ODA 

Open Document Architecture 

OS 

Output Specification 

O&S 

Operation and Support 

OSI 

Open Systems Interconnection 

PC 

Personal Computer 

PDL 

Page Description Language 

P&D 

Production and Deployment 

PHD/NSWC 

Port Hueneme Division, Naval Surface Warfare Center 

PMC 

President's Management Council 

PM JCALS 

Program Manager JCALS 

RIP 

Request For Proposal RFP 

RIG 

Regional Interest Groups 

RISC 

Reduced Instruction Set Computing 

ROK 

Republic of Korea 

SGML 

Standard Generalized Markup Language 

SOSC 

System operational Support Center 

SOW 

Statement of Work 

TACOM 

Tank Automation Command 

TCP/IP 

Transmission Control Protocol/Intemet Protocol 

TDCC 

Transportation Data Coordinating Committee 

TOP 

Technical Data Package 

TMCR 

TM Contract Requirements 

TMIS 

Technical Management Information System 

TMs/TOs 

Technical Manuals or Technical Orders 

TRM 

Technical Reference Model 

USFK 

United States Forces in Korea 

UN/EDIFACT 

United Nations/Electronic Data Interchnage For Administration, 
Commerce, and Transport 

VAN 

Value-Added Communication Network 

VHDL 

Very Hardware Description Language 

VHSIC 

Very High Speed Integrated Circuit 

VT 

Virtual Terminal 

WORM 

Write Once Read Many-times 
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WRA 

wss 

WWW 


Weapon Replaceable Assemblies 
Workstation Server 
World Wide Web 


110 



LIST OF REFERENCES 


1. CALS Industry Steering Group, "CALS 101 Tutorial, CALS EXPO '92", 1992. 

2. CALS/CE Industry Steering Group, "CALS EXPO International '94" (Proceedings 
and Reference) , December, 1994. 

3. Department of Defense, "CALS Strategic Plan," October 28, 1993. 

4. Fuhs, Hans G., "Application of the CALS Initiative to the Evolved Seasparrow 
Missile Program," Thesis, Naval Postgraduate School: Monterey, California, 
March, 1995. 

5. Hong, Jang Eui, Fax Message, June 25, 1995. 

6. Ministry of National Defense of Korea, "Defense White Paper," 1993-1994. 

7. Snodgrass, A. Wayne, "Small manufacturers-the missing communications link!," 
CALS/Enterprise Integration Journal, Winter, 1994. 

8. Department of Defense, "MIL-HDBK-59B," June 10, 1994. 

9. Program Manager JCALS (PM JCALS), "Generic prototyping: second in a two part 
series," JCALS Connection, Fall/Winter, 1994. 

10. Program Manager JCALS, "Deployment Plan," March 30, 1995. 

11. CALS Resource and Implementation Cooperative (RIC) Naval Air Warfare Center 
Aircraft Division Indianapolis, "Navy/Marine Corps Manager's Desktop Guide for 
CALS Implementation," September 30, 1994. 

12. Computer Science Corporation, "Site Manual for the Technical Manual Prototyping 
Requirements (Prototy Site 5 -Port Hueneme, Naval Surface Warfare Center)," 
June 13, 1994. 

13. Tomlinson, James E., "PM JCALS and the JCALS program," Logistics Spectrum, 
Fall, 1994. 

14. PM JCALS, "Deployment Plan," Office of the PM JCALS, March 30, 1995. 

15. Larson, Judy, and Tomlinson, James E. "Section 4: JCALS Joint Computer-Aided 
Acquisition and Logistics Support (JCALS) Implementation and Post Deployment 
Plan," PM/JCALS, Computer Science Corporation. 


Ill 


16. Bovard, P. (editor), "JCALS Background and System Description," Computer 
Sciences Corp., December, 1994. 

17. Department of Defense, "MIL-HDBK-59A: CALS Implementation Guide," 
June 10, 1990. 

18. Smith, J. M., "CALS: An Introduction to CALS the Strategy and Standards," 
Technology Appraisals: U.K, 1990. 

19. Stallings, W., "Data and Computer Communications: 4th Edition," Macmillan: 
New York, N.Y., 1994. 

20. Sprague, R. H. Jr. and McNurlin, B. C., "Information Systems Management in 
Practice: 3rd Edition," Prentice Hall: New Jersey, 1993. 

21. Pao, Hua-Fu, " Security Management of EDI," Thesis, Naval Postgraduate School: 
Monterey, California, June, 1993. 

22. Houser, W., "EDI Meets the Internet," Internet: ftp://ds.intemet.net/intemet-draft- 
ietf-edi-faq-00.txt. July, 1995. 

23. Erwin, F. D., "Electronic commerce in the federal government: Is it real?," 
CALS/Enterprise Integration Journal (Formerly CALS Journal), Winter, 1994. 

24. Favreau, J., "NIST role in the development of federal implementation convention," 
CALS EXPO International '94 Information Technology, CALS/CE Industry Steering 
Group, December, 1994. 

25. Ulery, D. L. and Wimple, C., "The future of CALS interchanges with UN/EDIFACT 
standards," CALS/Enterprise Integration Journal (Formerly CALS Journal), Winter, 
1994. 

26. Hill, N. C., and Ferguson, D. M., "Electronic Data Interchange: A Definition and 
Perspective," Internet: ftp://www.premenos.eom/t.edigroup/joumaFsamplel.html, 
August, 1995. 

27. Ellingen, D. C., "EDI on the Internet: Security through digital signatures and strong 
encryption," EDI World, January, 1995. 

28. Department of Defense , "MIL-STD-974: CITIS," August 20, 1993. 

29. InterLinear Technology, Inc., "The Effects of CALS Engineering Document 
Management Systems," 1995. 


112 


30. Beatty, Carol, "Implementing advanced manufacturing technologies: Rules of the 
road," Sloan Management Review, Summer, 1992. 

31. Davidovich, S. M. and Heisterberg, R. H., "Attacking CALS culture shock," CALS 
Journal, Summer, 1993. 

32. Endoso, Joyce, "$5 billion later, CALS initiative is 'in disarray 1 Glenn, GAO say," 
Government Computer News, October 17, 1994. 

33. Tomlinson, James E., "Joint computer-aided acquisition and logistics support tools 
for enterprise integration," CALS EXPO International '94 (Proceedings and 
Reference), CALS/CE Industry Steering Group, December, 1994. 

34. Department of Defense, "Department of Defense Electronic Commerce/Electronic 
Data Interchange Standards," Internet: http://www.itsi.disa.mil/edi/edi-main.html, 
August, 1995. 

35. Schein, "Organization, Culture & Leadership," 1991. 

36. Lee, Y., "The ministry of information & communication (MIC): Introduction, 
background & vision of CALS," Electronic Newspaper, Korea, February 24, 1995. 

37. Allen, Thomas John, "Managing the Flow of Technology," The Massachusetts 
Institute of Technology, 1978. 


113 


114 


INITIAL DISTRIBUTION LIST 


1. Defense Technical Information Center 2 

Cameron Station 

Alexandria, Va. 22304-6145 

2. Library Code 052 2 

Naval Postgraduate School 

Monterey, CA 93943-5000 

3. Professor Myoung W. Suh 1 

Department of Systems Management (Code SM/Su) 

Naval Postgraduate School 
Monterey, CA 93943-5000 

4. Professor Keebom Kang 1 

Department of Systems Management (Code SM/Kk) 

Naval Postgraduate School 
Monterey, CA 93943-5000 

5. Headquarter of Republic of Korea Army 1 

Individual Education Office 

P.O. Box 4 

Nonsan-gun, Duma-myon, Bunam-ri 
South-Chung, Korea, 320-819 

6. CPT Jun Sang Jo, ROK Army 2 

357-1 Gongduk-dong, Mapo-gu 

Seoul, Korea 121-022 


115 


